Hallo,
ich selbst habe noch keine Homematic Geräte jedoch wollte ich mir zum Testen und spielen mal ein paar Heizungsthermostate(HM-CC-RT-DN) und den HM Lan Adapter bestellen.
Die Thermostate haben ja einen eingebauten Tempsensor mithilfen diesens steuert ja auch das Ventil. Bei meiner überlegung würde ich aber zu steuerung gerne ein Temperaturfühler verwenden welcher wo anders im Raum ist und nicht mit dem Thermostat gepeert ist. (Funksensoren über LaCrosse).
Jetzt habe ich bevor ich das alles Bestelle eine grundsatz Frage: Kann ich dem Homematic Thermostat (HM-CC-RT-DN) sagen (mit fhem) es soll sich bei seiner Regulierung nicht an das eigene sondern an mein Lacrosse Sensor halten? Und wenn ja wie würde man das im groben machen?
ich habe nun diesen beitrag gefunden http://forum.fhem.de/index.php/topic,17485.45.html
jedoch wird da nur berichtet dass es irgendwie gelungen ist, aber wie ist mir nicht ganz klar geworden. villeicht kann dazu mal jemand was sagen
Würde mich über eine Antwort freuen,
MfG
Abend,
ja das funktioniert. Ist aktuell noch ein recht neues Feature und kann noch Bugs enthalten. Geht aber bereits. Grob geht es so:
define virtual_temp CUL_HM 123456 (die hm id muss eindeutig sein)
set virtual_temp virtual 1
rename virtual_temp_Btn1 virtual_temp_Sensor1 (damits sinniger klingt)
set virtual_temp_Sensor1 peerChan 0 dein_rt single
Nun hast du einen virtuellen Temperatursensor. Den musst du jetzt nur noch mit der aktuellen Temperatur deines echten Sensors füttern:
set virtual_temp_Sensor1 virtTemp 22
Das kannst du dann z.B. mit einem notify machen.
Gruß,
Jan
Das Feature an sich ist nicht neu. Die Verwendung von Homematic Sensoren mit dem RT geht schon immer out-of-the-box.
Neu ist nur die Möglichkeit, auch systemfremde Sensoren zusammen mit dem Regler zu betreiben. Wobei ich kein Freund von virtuellen Homematic-Aktoren bin.
Also generell ist das Feature nach dem er gefragt hat recht neu und wenig erprobt. Allerdings sollte man das prinzipiell stabil bekommen können. Wenn es Probleme gibt haben wir mehrere User die das nachstellen können und generell ist das Vorgehen ganz gut verstanden würde ich behaupten.
Natürlich sind HM Sensoren besser aber auch recht teuer. Ich werde für einige Räume auch virtTemp/virtHumidity verwenden, weil da eh ein AP mit Temperatursensor rumhängt.
Gruß,
Jan
ok vielen dank schonmal, dann werde ich zum testen mal so ein heizungstermostat bestellen, und mich ggf dann nochmal melden.
Hallo,
sehe ich das richtig, dass:
Zitatdefine virtual_temp CUL_HM 123456 (die hm id muss eindeutig sein)
die eindeutige HM id diejenige ist Fhem beim Pairen mit in den Namen rein nimmt? Bei mir z. B. der String 235C60 aus dem Namen CUL_HM_HM_CC_RT_DN_235C60?
Zitatrename virtual_temp_Btn1 virtual_temp_Sensor1
müsste es nicht heißen
rename virtual_temp virtual_temp_Sensor1??
Zitatset virtual_temp_Sensor1 peerChan 0 dein_rt single
dein_rt ist dann z. B. bei mir CUL_HM_HM_CC_RT_DN_235C60??
Diese Fragen sind mir noch unklar und ich konnte mir vorstellen, dass andere sich das auch fragen...
Danke für eure Mühe!!
Bene[/size]
Moin Bene,
Zitat von: Bene am 06 Februar 2014, 10:42:54
die eindeutige HM id diejenige ist Fhem beim Pairen mit in den Namen rein nimmt? Bei mir z. B. der String 235C60 aus dem Namen CUL_HM_HM_CC_RT_DN_235C60?
Nein das ist die ID des virtuellen Sensors. Die darf auf keinen Fall gleich der des RTs sein. Sie muss unbenutzt sein.
Zitat von: Bene am 06 Februar 2014, 10:42:54
müsste es nicht heißen rename virtual_temp virtual_temp_Sensor1??
Nein. Das ist schon richtig so. Ich habe das alles ausprobiert. Die folgende Zeile legt virtual_temp_Btn1 an:
set virtual_temp virtual 1
Man kann auch virtual 7 machen. Dann hat man Btn1 bis Btn7 und kann sich sieben Sensoren bauen. Das Naming mit Btn ist etwas unglücklich für Sensoren, aber da wir bisher nur virtuelle Aktoren (aka Buttons) hatten war das ok. Vielleicht kann man das jetzt noch mal überdenken.
Zitat von: Bene am 06 Februar 2014, 10:42:54
dein_rt ist dann z. B. bei mir CUL_HM_HM_CC_RT_DN_235C60??
Ja.
Gruß,
Jan
Danke, jab, für deine ausführliche Antwort! Sie bringt mich in meinem Verständnis ein gutes Stück weiter.
Eines aber noch:
Zitat
Nein das ist die ID des virtuellen Sensors. Die darf auf keinen Fall gleich der des RTs sein. Sie muss unbenutzt sein.
Der virtuelle Sensor ist also der 1-wire-sensor? Oder ist das wirklich ein "ausgedachter" Sensor, dessen ID ich selber ausdenken kann?
Mir geht es ja um die Abbildung des Temperaturwertes eines 1-Wire-Sensors auf den RT...
Irgendwie muss ich dann auch den richtigen Sensor dem passenden RT zuweisen.... An welcher Stelle passiert das?
Ich blicke es noch nicht...
Danke!!
Moin Bene,
Die ID ist ausgedacht. Das Gerät gibt es ja eigentlich nicht als HM Gerät. Die Verbindung bzw das peering zwischen den Geräten macht der Befehl peerChan. Da gibst du den virtuellen Sensor und den echten RT an.
Gruß
Jan
Ich habe da auch noch ne Frage.
Würde das auch mit einem Virtual Device gehen, das die Desired-Temp und Boost-Funktionen auslösen kann, also praktisch ein HM-TC-IT-WM-W-EU emuliert?
Wenn ich heimkomme setze ich nämlich alle Thermostate auf die Boost Funktion momentan sende ich dazu einen Funkbefehl an jedes Thermostat, das dauert natürlich seine Zeit und verursacht natürlich auch entsprechend Funkverkehr weil ich das mit burstRX mach (ich will ja nicht noch 3 minuten warten bis jedes Thermostat den Befehl empfangen hat).
Ist das möglich?
mir ist nicht klar, wie der TC-IT arbeitet. Sendet der einen broadcast?
Der RT hat einen Eingang für Fernbedienung - die kannst du auch nutzen. Aber das geht auch an jedes Device separat. Generell ist dies sowieso notwendig, will man ein ack bekommen.
Hallo Martin,
Zitatmir ist nicht klar, wie der TC-IT arbeitet. Sendet der einen broadcast?
Ja genau das würde ich gerne wissen. Ob das irgendwie möglich ist.
ZitatDer RT hat einen Eingang für Fernbedienung - die kannst du auch nutzen. Aber das geht auch an jedes Device separat. Generell ist dies sowieso notwendig, will man ein ack bekommen.
Das mit dem ACK macht Sinn, aber darauf könnte ich ja auch mal verzichten. Wie ist das denn, wenn ein RT mit 3 anderen gepeert ist und ich an einem die desired-temp ändere. Wird das dann auch an jeden Seperat gesendet? Müsste ja dann im eventmonitor zu sehen sein oder?
Muss ich mir heute Abend mal anschauen.
Hi Samsi,
ZitatWie ist das denn, wenn ein RT mit 3 anderen gepeert ist.... Wird das dann auch an jeden Seperat gesendet
der sendet garnicht.
Die Philosophie scheint zu sein, dass nur Änderungen gesendet werden, die nicht von extern kommen. Alles was von extern kommt kann der User sowieso automatisieren.
Also keine Message bei Fenster offen von sc oder temp von der Zentrale.
Demnach eigentlich nur bei Änderung am Handrad (und interner Fenster offen Erkennung???)
Und wenn gesendet wird, dann nach HM schema - an jeden einzeln, mit ack
Möglich - aber nicht getestet - wäre folgendes:
der RT wird an eine remote gepeert, die remote aber nicht an den RT. Die Remote sendet an die Zentrale oder broadcast (muss burst sein). Könnte sein, dass der RT darauf reagiert. Kannst du einmal testen - vielleicht probiere ich es auch einmal...
Gruss Martin
Zitat von: jab am 03 Februar 2014, 01:52:01
Abend,
ja das funktioniert. Ist aktuell noch ein recht neues Feature und kann noch Bugs enthalten. Geht aber bereits. Grob geht es so:
define virtual_temp CUL_HM 123456 (die hm id muss eindeutig sein)
set virtual_temp virtual 1
rename virtual_temp_Btn1 virtual_temp_Sensor1 (damits sinniger klingt)
set virtual_temp_Sensor1 peerChan 0 dein_rt single
Nun hast du einen virtuellen Temperatursensor. Den musst du jetzt nur noch mit der aktuellen Temperatur deines echten Sensors füttern:
set virtual_temp_Sensor1 virtTemp 22
Das kannst du dann z.B. mit einem notify machen.
Gruß,
Jan
Hallo Jan,
ich bekomme es nicht hin. Ich habe versucht über ein notify die Temperatur meines S300Th auf meinen virtuellen HM Sensor zu kopieren. Da ich von Perl leider keine Ahnung habe, mußte ich mir dies erst relativ aufwendig zusammensuchen und mit try and error austesten.
So sieht es jetzt in meiner FHEM.cfg aus:
define EG.WZ.VIRT.TEMP CUL_HM 123456
attr EG.WZ.VIRT.TEMP model virtual_1
attr EG.WZ.VIRT.TEMP peerIDs
attr EG.WZ.VIRT.TEMP subType virtual
attr EG.WZ.VIRT.TEMP webCmd virtual
define EG.WZ.VIRT.TEMP_Sensor1 CUL_HM 12345601
attr EG.WZ.VIRT.TEMP_Sensor1 model virtual_1
attr EG.WZ.VIRT.TEMP_Sensor1 peerIDs 21BC5301,
define nEG.WZ.VIRT.TEMP notify wz_temp:temperature:.* {fhem 'set EG.WZ.VIRT.TEMP_Sensor1 ' . $EVTPART1}Und das ist die Fehlermeldung die ich bekomme:
2014.02.09 18:38:52 3: set EG.WZ.VIRT.TEMP_Sensor1 21.6 : Unknown argument 21.6, choose one of peerChan postEvent press virtHum:off,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,30.5,31.0,31.5,32.0,32.5,33.0,33.5,34.0,34.5,35.0,35.5,36.0,36.5,37.0,37.5,38.0,38.5,39.0,39.5,40.0,40.5,41.0,41.5,42.0,42.5,43.0,43.5,44.0,44.5,45.0,45.5,46.0,46.5,47.0,47.5,48.0,48.5,49.0,49.5,50.0,50.5,51.0,51.5,52.0,52.5,53.0,53.5,54.0,54.5,55.0,55.5,56.0,56.5,57.0,57.5,58.0,58.5,59.0,59.5,60.0,60.5,61.0,61.5,62.0,62.5,63.0,63.5,64.0,64.5,65.0,65.5,66.0,66.5,67.0,67.5,68.0,68.5,69.0,69.5,70.0,70.5,71.0,71.5,72.0,72.5,73.0,73.5,74.0,74.5,75.0,75.5,76.0,76.5,77.0,77.5,78.0,78.5,79.0,79.5,80.0,80.5,81.0,81.5,82.0,82.5,83.0,83.5,84.0,84.5,85.0,85.5,86.0,86.5,87.0,87.5,88.0,88.5,89.0,89.5,90.0,90.5,91.0,91.5,92.0,92.5,93.0,93.5,94.0,94.5,95.0,95.5,96.0,96.5,97.0,97.5,98.0,98.5,99.0 virtTemp:off,-20.0,-19.5,-19.0,-18.5,-18.0,-17.5,-17.0,-16.5,-16.0,-15.5,-15.0,-14.5,-14.0,-13.5,-13.0,-12.5,-12.0,-11.5,-11.0,-10.5,-10.0,-9.5,-9.0,-8.5,-8.0,-7.5,-7.0,-6.5,-6.0,-5.5,-5.0,-4.5,-4.0,-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,30.5,31.0,31.5,32.0,32.5,33.0,33.5,34.0,34.5,35.0,35.5,36.0,36.5,37.0,37.5,38.0,38.5,39.0,39.5,40.0,40.5,41.0,41.5,42.0,42.5,43.0,43.5,44.0,44.5,45.0,45.5,46.0,46.5,47.0,47.5,48.0,48.5,49.0,49.5,50.0
2014.02.09 18:38:52 3: nEG.WZ.VIRT.TEMP return value: Unknown argument 21.6, choose one of peerChan postEvent press virtHum:off,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,30.5,31.0,31.5,32.0,32.5,33.0,33.5,34.0,34.5,35.0,35.5,36.0,36.5,37.0,37.5,38.0,38.5,39.0,39.5,40.0,40.5,41.0,41.5,42.0,42.5,43.0,43.5,44.0,44.5,45.0,45.5,46.0,46.5,47.0,47.5,48.0,48.5,49.0,49.5,50.0,50.5,51.0,51.5,52.0,52.5,53.0,53.5,54.0,54.5,55.0,55.5,56.0,56.5,57.0,57.5,58.0,58.5,59.0,59.5,60.0,60.5,61.0,61.5,62.0,62.5,63.0,63.5,64.0,64.5,65.0,65.5,66.0,66.5,67.0,67.5,68.0,68.5,69.0,69.5,70.0,70.5,71.0,71.5,72.0,72.5,73.0,73.5,74.0,74.5,75.0,75.5,76.0,76.5,77.0,77.5,78.0,78.5,79.0,79.5,80.0,80.5,81.0,81.5,82.0,82.5,83.0,83.5,84.0,84.5,85.0,85.5,86.0,86.5,87.0,87.5,88.0,88.5,89.0,89.5,90.0,90.5,91.0,91.5,92.0,92.5,93.0,93.5,94.0,94.5,95.0,95.5,96.0,96.5,97.0,97.5,98.0,98.5,99.0 virtTemp:off,-20.0,-19.5,-19.0,-18.5,-18.0,-17.5,-17.0,-16.5,-16.0,-15.5,-15.0,-14.5,-14.0,-13.5,-13.0,-12.5,-12.0,-11.5,-11.0,-10.5,-10.0,-9.5,-9.0,-8.5,-8.0,-7.5,-7.0,-6.5,-6.0,-5.5,-5.0,-4.5,-4.0,-3.5,-3.0,-2.5,-2.0,-1.5,-1.0,-0.5,0.0,0.5,1.0,1.5,2.0,2.5,3.0,3.5,4.0,4.5,5.0,5.5,6.0,6.5,7.0,7.5,8.0,8.5,9.0,9.5,10.0,10.5,11.0,11.5,12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0,30.5,31.0,31.5,32.0,32.5,33.0,33.5,34.0,34.5,35.0,35.5,36.0,36.5,37.0,37.5,38.0,38.5,39.0,39.5,40.0,40.5,41.0,41.5,42.0,42.5,43.0,43.5,44.0,44.5,45.0,45.5,46.0,46.5,47.0,47.5,48.0,48.5,49.0,49.5,50.0
Für mich sieht es jetzt so aus, daß nur .0 und .5 bei den Temperaturen erlaubt sind.
Stimmt das und wenn ja wie kann ich das ändern?
Es wäre super, wenn mir jemand helfen könnte,
Danke,
Martin
Hi Martin,
Das runden ist etwas tricky. Vermutlich ist es am einfachsten die Zahl mal 2 zu nehmen dann zu runden (ohne Nachkommastellen) und dann wieder durch zwei zu teilen. Also etwa so:
$new = int ($value*2)/2.0;
Gruß
Jan
Zitat von: DosiRocker am 09 Februar 2014, 19:05:53
Für mich sieht es jetzt so aus, daß nur .0 und .5 bei den Temperaturen erlaubt sind.
Stimmt das und wenn ja wie kann ich das ändern?
Hallo Martin (DosiRocker),
das kann ich so nicht bestätigen. Ich "füttere" den virtuellen TempSensor für den RT auch mit Temperaturen mit einer (beliebigen) Nachkommastelle - ohne Fehler.
Von eben:
2014.02.10 20:06:17 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.0
2014.02.10 20:06:31 2: CUL_HM set wz_vT_Sensor1 virtTemp 19.9
2014.02.10 20:14:09 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.0
2014.02.10 20:14:23 2: CUL_HM set wz_vT_Sensor1 virtTemp 19.9
2014.02.10 20:14:36 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.0
2014.02.10 20:14:50 2: CUL_HM set wz_vT_Sensor1 virtTemp 19.9
2014.02.10 20:15:17 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.0
2014.02.10 20:15:44 2: CUL_HM set wz_vT_Sensor1 virtTemp 19.9
2014.02.10 20:16:38 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.0
2014.02.10 20:17:45 2: CUL_HM set wz_vT_Sensor1 virtTemp 19.9
2014.02.10 20:18:12 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.0
2014.02.10 20:29:40 2: CUL_HM set wz_vT_Sensor1 virtTemp 20.1
Bei mir sieht der DEF-Part des notify so aus:
wz_ds_temp { fhem "set wz_vT_Sensor1 virtTemp $EVTPART1" }Zugehöriges Filelog des DS1820 Sensors:
2014-02-10_20:54:37 wz_ds_temp temperature: 20.0
2014-02-10_20:55:30 wz_ds_temp temperature: 20.1
2014-02-10_20:55:44 wz_ds_temp temperature: 20.0
Gruss
Tobias
Puh und ich dachte schon der versteht nur 0,5er schritte. Ich werd das heute Abend auch mal ausprobieren.
Allerdings muss ich mich dann erstmal um die korrekte Einbindung vom HM-cc-rt-dn kümmern. Hat da jemand eventuell mal ein Log von seinem Define eines hm rt?
Bei autocreate definiert er ja nur die minimalen Attribute.
Zusätzlich habe ich das Problem dass ich die Autoupdate Zeilen aus der fhem.cfg gelöscht habe. Kann mir die vielleicht auch jemand posten ?
Hi,
hier ist die Definition einer meiner RTs:
define og_bd_Heizung CUL_HM 21F833
attr og_bd_Heizung .devInfo 00FFFF
attr og_bd_Heizung .stc 59
attr og_bd_Heizung IODev HMLAN1
attr og_bd_Heizung actCycle 000:10
attr og_bd_Heizung actStatus alive
attr og_bd_Heizung autoReadReg 4_reqStatus
attr og_bd_Heizung expert 2_full
attr og_bd_Heizung firmware 1.0
attr og_bd_Heizung group og_Bad
attr og_bd_Heizung model HM-CC-RT-DN
attr og_bd_Heizung peerIDs
attr og_bd_Heizung room og_Bad
attr og_bd_Heizung serialNr KEQ0506349
attr og_bd_Heizung subType thermostat
attr og_bd_Heizung webCmd getConfig:burstXmit
define og_bd_Heizung_Weather CUL_HM 21F83301
attr og_bd_Heizung_Weather expert 1
attr og_bd_Heizung_Weather group og_Bad
attr og_bd_Heizung_Weather model HM-CC-RT-DN
attr og_bd_Heizung_Weather peerIDs 00000000,
define og_bd_Heizung_Climate CUL_HM 21F83302
attr og_bd_Heizung_Climate expert 1
attr og_bd_Heizung_Climate group og_Bad
attr og_bd_Heizung_Climate model HM-CC-RT-DN
attr og_bd_Heizung_Climate peerIDs 00000000,
define og_bd_Heizung_WindowRec CUL_HM 21F83303
attr og_bd_Heizung_WindowRec expert 1
attr og_bd_Heizung_WindowRec group og_Bad
attr og_bd_Heizung_WindowRec model HM-CC-RT-DN
attr og_bd_Heizung_WindowRec peerIDs 00000000,
attr og_bd_Heizung_WindowRec stateFormat last:trigLast
define og_bd_HeizungOp CUL_HM 21F83304
attr og_bd_HeizungOp expert 1
attr og_bd_HeizungOp group og_Bad
attr og_bd_HeizungOp model HM-CC-RT-DN
attr og_bd_HeizungOp peerIDs
attr og_bd_HeizungOp room og_Bad
define og_bd_Heizung_ClimaTeam CUL_HM 21F83305
attr og_bd_Heizung_ClimaTeam expert 1
attr og_bd_Heizung_ClimaTeam group og_Bad
attr og_bd_Heizung_ClimaTeam model HM-CC-RT-DN
attr og_bd_Heizung_ClimaTeam peerIDs 00000000,
define og_bd_Heizung_Remote CUL_HM 21F83306
attr og_bd_Heizung_Remote expert 1
attr og_bd_Heizung_Remote group og_Bad
attr og_bd_Heizung_Remote model HM-CC-RT-DN
attr og_bd_Heizung_Remote peerIDs 00000000,
Allerdings ist das alles durch autocreate entstanden, außer room, Group und der Namensgebung.
Ein autoupdate habe ich nicht, keine Ahnung wofür das gut ist.
Gruß,
Thorsten
Zitat von: tpm88 am 10 Februar 2014, 20:59:53
wz_ds_temp { fhem "set wz_vT_Sensor1 virtTemp $EVTPART1" }
[/code]
Gruss
Tobias
Hallo Tobias,
es scheint bei mir jetzt auch zu funktionieren. Muß leider wieder meine mangelnden Perl Kenntnisse beklagen. Vielen Dank für deine Hilfe.
@blackdevil2k1:
Bei mir wurde auch alles durch autocreate angelegt.
Was benötigst du denn speziell?
Gruß,
Martin
Hatte alles so gemacht wie beschrieben ... und hat auch wunderbar funktioniert (virtueller HM-Tempsensor angelegt und mit dem RT gepeert).
Habe dann aber nochmal "umstrukturiert", den alten virtuellen HM gelöscht und einen neuen angelegt (an einem bereits bestehenden virtuellen HM) und diesen dann neu auf den RT gepeert.
Aber das ging irgendwie in die Hose ... der RT hat als STATE jetzt "NACK" ... wie bekomme ich das krumme Peering wieder geradegebogen?
Ich hatte vergessen nach dem Pairen des RT dann nochmal auf Save Config zu drücken, deswegen fehlten mir alle attribute. Jetzt aber sind sie da. Für meinene virtTEmp hatte ich gestern keine Zeit mehr, ich werd das aber evtl heut abend ausprobieren... soweit alles gut
Zitat von: roedert am 11 Februar 2014, 11:29:07
Habe dann aber nochmal "umstrukturiert", den alten virtuellen HM gelöscht und einen neuen angelegt (an einem bereits bestehenden virtuellen HM) und diesen dann neu auf den RT gepeert.
Aber das ging irgendwie in die Hose ... der RT hat als STATE jetzt "NACK" ... wie bekomme ich das krumme Peering wieder geradegebogen?
NACK heißt nur dass der RT überfordert ist. Gib ihm etwas Zeit und versuch es noch mal.
Gruß,
Jan
Ich habe jetzt nochmal alles sauber eingerichet - ein S300TH, der über einen Notify seinen aktuellen Wert an den virtuellenHM-Sensor übergibtt, dieser ist mit dem RT gepeert.
Manchmal sehe ich den Wert des S300TH auch als measured-Temp im RT, jedoch stehen dort auch Werte die um 1-2 Grad davon abweichen. Im Graph von measured-Temp des RT ist also ein wildes Springen der measured-Temp im Bereich von 1-2 Grad ... keine Ahnung wo das herkommt. Der Graph des S300TH bzw. auch des daraus gefüllten virtuellenHM ists absolut glatt. Dementsprechend wird auch der Actor wie wild geregelt, was natürlich auf die Batterielaufzeit geht.
Schade, da ich ja schöne Temperaturwerte vom S300TH habe .... der am RT selbst gemessene Wert ist nicht so optimal, da sich dieser in einer Nische befindet und somit sehr mit dem Actutor schwankt.
Hi,
Zitat von: roedert am 11 Februar 2014, 17:23:22
Ich habe jetzt nochmal alles sauber eingerichet - ein S300TH, der über einen Notify seinen aktuellen Wert an den virtuellenHM-Sensor übergibtt, dieser ist mit dem RT gepeert.
Manchmal sehe ich den Wert des S300TH auch als measured-Temp im RT, jedoch stehen dort auch Werte die um 1-2 Grad davon abweichen. Im Graph von measured-Temp des RT ist also ein wildes Springen der measured-Temp im Bereich von 1-2 Grad ... keine Ahnung wo das herkommt. Der Graph des S300TH bzw. auch des daraus gefüllten virtuellenHM ists absolut glatt. Dementsprechend wird auch der Actor wie wild geregelt, was natürlich auf die Batterielaufzeit geht.
Schade, da ich ja schöne Temperaturwerte vom S300TH habe .... der am RT selbst gemessene Wert ist nicht so optimal, da sich dieser in einer Nische befindet und somit sehr mit dem Actutor schwankt.
Komisch. Bei mir passiert das eigentlich nicht. Kannst du mal für ein paar Minuten den Funk mitschneiden und Raw Messages schicken?
attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys
Gruß,
Jan
Hallo,
ich habe mich heute Nacht auch mal dran gemacht meine Lacrosse Tempsensoren über ein virtTemp mit meinen HM-CC-RT-DN zu peeren. Das hat soweit auch geklappt, obwohl man wissen muss dass es scheinbar nicht reicht die fhem.cfg entsprechend zu schreiben. Jedenfalls wird dann das peering nicht in die RTs übertragen, mit set wirds dann direkt auch übertragen.
Jetzt habe ich aber noch ein paar generelle Homematic Fragen. Bei Änderungen zb der desired-temp steht meist erstmal ne weile CMDs_pending beim status der RTs, irgendwann wirds dann gesendet. Wie oft wird denn gesendet? Meine Vermutung ist dass es mit hmLanQlen bei meinem HMLan Konfigadapter zu tun hat. Ist das extra so gemacht damit nicht zuviel pro Std. gesendet wird?
Wenn das so ist, wie funktioniert das denn dann mit den gepeerten Geräten. An meine RTs sind nun virtuelle Temp Sensoren gepeert. Werden diese Syncronisiert wenn das RT aufwacht? Laut wiki all 2,5min?
Hi,
soweit ich das verstehe wacht der RT tatsächlich so ungefähr alle 2 bis 3 Minuten auf und sendet etwas. Daraufhin kann dann FHEM oder ein gepeertes Gerät etwas mitschicken. Während der RT schläft kann man gar nicht mit ihm kommunizieren. Ich gehe mal davon aus, dass das hauptsächlich zum Stromsparen so gemacht wurde. Ansonsten müssten die Geräte andauernd mithören, was auf die Batterie geht. Aber wahrscheinlich ist's auch wegen der 1%-Regel.
Man kann natürlich mit Burst arbeiten, aber das geht dann wieder auf die Batterie (von jedem Gerät in der Umgebung) und auf das 1%-Budget (siehe Wiki zum RT). Ich gehe mal nicht davon aus, dass virtTemp Burst-Messages benutzt. Soweit ich verstehe, war das Herausfinden des exakten Timings die große Herausforderung beim Implementieren von virtTemp.
Gruß,
Thorsten
ok, meine frage nun ist, was passiert wenn das RT ne weile nix von seinem gepeerten Temperaturfühler bekommt. mit welchem Wert rechnet es dann? Schaltet es irgendwann aufs interne um?
Zitat von: blackdevil2k1 am 13 Februar 2014, 18:42:58
ok, meine frage nun ist, was passiert wenn das RT ne weile nix von seinem gepeerten Temperaturfühler bekommt. mit welchem Wert rechnet es dann? Schaltet es irgendwann aufs interne um?
Das wäre denkbar und würde auch die bei mir in Diagramm festgestellten ständigen Temperatursprünge der MeasuredTemp des RT erklären. Aktuell habe ich es wieder deaktiviert und hatte auch noch nicht die Zeit den gewünschten Mitschnitt des Funkverkehrs zur Verfügung zu stellen.
Lt. Bedienungsanleitung des RT kann man unter dem Punkt "dEL" angelernte Geräte wieder ablernen. Diesen Punkt gab e sbei mir gar nicht .. ein Zeichen dafür, dass gar kein Gerät angelernt war. Oder müsste der virtuelleHM-Sensor dort nicht auftauchen?
Abend,
Wenn das Gerät gepaired mit einer zentrale ist dann geht sowas nur noch über die zentrale. Wie das Verhalten bei ausgefallenem Sensor ist müsste man testen. Vermutlich muss man dafür circa eine Stunde warten.
Gruß Jan
Hallo,
Zitat von: roedert am 11 Februar 2014, 17:23:22
Manchmal sehe ich den Wert des S300TH auch als measured-Temp im RT, jedoch stehen dort auch Werte die um 1-2 Grad davon abweichen. Im Graph von measured-Temp des RT ist also ein wildes Springen der measured-Temp im Bereich von 1-2 Grad ... keine Ahnung wo das herkommt. Der Graph des S300TH bzw. auch des daraus gefüllten virtuellenHM ists absolut glatt. Dementsprechend wird auch der Actor wie wild geregelt, was natürlich auf die Batterielaufzeit geht.
Bei meinem mit einem 1wire Temperatursensor virtuell gekoppelten RT sehe ich diese Sprünge leider auch.
Meine erste Vermutung war, dass die Firmware 1.0 des RT die Ursache hierfür ist. So sah das vor dem Firmware Update aus:
=> siehe Screenshot im Anhang HMvtemp1.PNG
Nach dem Update des RT auf Firmware 1.2 sieht es viel besser aus - die Sprünge sind nur noch sporadisch aber nicht ganz weg:
=> siehe Screenshot im Anhang HMvtemp2.PNG
Bei den Bildern ist jeweils oben der (glatte) Graph des 1wire Sensors und unten der Graph der Readings des RTs.
Zitat von: Thorsten Pferdekaemper am 13 Februar 2014, 09:28:07
... Ich gehe mal nicht davon aus, dass virtTemp Burst-Messages benutzt. Soweit ich verstehe, war das Herausfinden des exakten Timings die große Herausforderung beim Implementieren von virtTemp.
Fakt ist, beim Anlegen des virtuellen Peers wurde automatisch (durch FHEM??) zeitgleich der Burst Modus aktiviert (R-burstRx = on). Ich hatte alle meine RTs vorher ausschliesslich im WakeUp Mode betrieben. Mein Verständnis ist auch, dass das Peering eines HM Fensterschalters oder Temperatursensors immer den BurstModus beim RT aktiviert. Die Frage ist jetzt, ob FHEM die virtTemp Messages dann auch via Burst verschickt?? => Martin?
Zitat von: blackdevil2k1 am 13 Februar 2014, 18:42:58
ok, meine frage nun ist, was passiert wenn das RT ne weile nix von seinem gepeerten Temperaturfühler bekommt. mit welchem Wert rechnet es dann? Schaltet es irgendwann aufs interne um?
Glaube ich eher nicht - wenn ich meine Graphen vergleiche, kommt es bei mir eher zu Sprüngen, wenn die Temperatur ständig um ein Zehntel Grad oszilliert, also vielleicht zu viele virtTemp Messages durch den notify getriggert werden??
Der Mitschnitt der Raw Messages war mir bisher zu mühsam, da bei mir die Sprünge nur sehr sporadisch auftreten. Mein nächster Test wird sein, statt des Senden aller virtTemp Änderungen via notify den Temperaturwert des Sensors via at nur noch in festen Intervallen (z.B. 5 Minuten) zu senden. Die Fenster-Auf Funktion des RT wird durch die geglättete Kurve des Temperatursenors sowieso "torpediert".
Gruss
Tobias
Konnte jemand die spontanen Schwankungen beheben?
Zitat von: jab am 03 Februar 2014, 01:52:01
Abend,
ja das funktioniert. Ist aktuell noch ein recht neues Feature und kann noch Bugs enthalten. Geht aber bereits. Grob geht es so:
define virtual_temp CUL_HM 123456 (die hm id muss eindeutig sein)
set virtual_temp virtual 1
rename virtual_temp_Btn1 virtual_temp_Sensor1 (damits sinniger klingt)
set virtual_temp_Sensor1 peerChan 0 dein_rt single
Nun hast du einen virtuellen Temperatursensor. Den musst du jetzt nur noch mit der aktuellen Temperatur deines echten Sensors füttern:
set virtual_temp_Sensor1 virtTemp 22
Das kannst du dann z.B. mit einem notify machen.
Gruß,
Jan
Hallo,
Ich habe mir auch ein paar HM-CC-RT-DN zum Spielen zugelegt.
Die Ist Temperatur soll dabei von 1-Wire DS18B20 Sensoren kommen.
Die Home Matic Thermostate habe ich in FHEM eingebunden, die 1-Wire Sensoren sind eingebunden und liefern auch brav ihre Werte. Jetzt habe ich mit o.g. Befehlen versucht den 1-Wire Sensor mit dem Thermostat zu verbinden, bin aber kläglich gescheitert.
Wahrscheinlich habe ich vor lauter basteln am Wochenende einen Knoten im Hirn. Kann mich jemand wieder in die richtige Richtung lenken?
das funktioniert bei mir einwandfrei. Hier nochmal Schritt für Schritt:
1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>
2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1
3. Bei uns ist es kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1
4. Virtuellen Peer Sensor mit dem Weather Channel deines RT-DN peeren:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single
5. Peering kontrollieren (Voraussetzung: Device hm vom Type hmInfo existiert):
set hm peerXref
Beispiel-Ausgabe bei mir:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather
6. Gemessene Temperatur vom 1w DS1820 dem virtuellen HM Sensor übergeben. Ich mache das alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }
Fertig.
Wenn es bei dir klemmt, poste doch mal die Ausgaben von:
list <dein_virtuelles_HM_Device>
list <dein_virtueller_temperatur_Sensor>
list <dein_RT_DN>_Weather
Gruß
Tobi
Zitat von: tpm88 am 21 Dezember 2014, 22:50:56
6. Gemessene Temperatur vom 1w DS1820 dem virtuellen HM Sensor übergeben. Ich mache das alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }
Hallo Tobi,
Danke für deine schnelle Hilfe. Ich wollte den DS1820 mit mit dem virtuellen Sensor koppeln, das macht natürlich keinen Sinn.
Ich habe jetzt nur noch ein kleines Problem: Wenn ich o.g. Zeile in die Config einfüge, kommt beim 2. Teil
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("DS18B20_E43A56050000","temperature",20.0));; fhem "set wz_vT_Sensor1 virtTemp "$T} ein Fehler:
Zitatat_wz_vT already defined, delete it first
Unknown command fhem, try help.
Von den Klammern und "" her scheint der Befehl richtig zu sein.
Gruß,
Sebastian
Hallo Sebastian,
stimmt - zumindest den
Unknown command fhem, try help.
bekomm ich auch.
In jedem Fall funktioniert folgendes Vorgehen - und zwar über die Eingabe im Kommandofeld vom FHEMWEB Frontend. Ich editiere eigentlich grundsätzlich nicht direkt in der fhem.cfg...
Ggf. das at_wz_vT vorher noch einmal per delete löschen.
define at_wz_vT at +*00:02 {}
Anschließend auf der Detailseite des gerade angelegten leeren at "DEF" anklicken und im Editor die eigentlichen Perl Kommandos in die geschweiften Klammern einfügen und per modify und anschliessendem save "festzurren"...
DEF:
{ my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }
Tobi
Hallo Tobi,
jetzt scheint es zu laufen, ich habe alle 2 Mintuen folgendes im Log:
Zitat
2014.12.22 12:27:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.9375
2014.12.22 12:29:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.9375
2014.12.22 12:31:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.875
2014.12.22 12:33:15 3: CUL_HM set wz_vT_Sensor1 virtTemp 20.9375
Das peering schaut gut aus:
ZitatpeerXref done:
x-ref list
wz_vT_Sensor1 => Bad.Heizung.IST (Weather Channel des Thermostat)
Nur das Senden der Temperaturen scheint noch nicht zu laufen. Das sollte ich doch auch im Log sehen können?
Vg
Sebastian
ZitatDas peering schaut gut aus:
wenn das alles ist, fehlt der rückkanal. ein fehler sollte dann bei hminfo configcheck auftauchen.
gruss frank
Hallo Frank,
Danke für den Hinweis. Der Rückkanal war nicht vorhanden.
Nachdem ich das ganze nochmal probiert habe, übernimmt das Thermostat jetzt tatsächlich die Daten vom 1-Wire sensor.
Vielen dank euch beiden für die schnelle und kompetente Hilfe.
Hi,
Ich habe 3 Lacrosse Sender und 3 Homematic Heizungsthermostate.
Die habe ich nach dieser Anleitung verbunden.
Bei zweien klappt alles einwandfrei, aber bei einem nicht.
Hier übernimmt der Weather Channel irgendwann die Werte aus dem virtuellen Sensor nicht mehr.
Meist läuft es ein paar Stunden, dann springt das Thermostat wieder auf den internen Fühler.
Im Display fängt dann auch das Antennen Symbol an zu blinken, was ja normalerweise dauerhaft leuchtet.
Im virtuellen Sensor sind alle Werte jeweils richtig übergeben, es hängt also irgendwo zwischen dem Sensor und dem Thermostat.
Leider bin ich noch total neu, bin für jede Hilfe dankbar.
Viele Grüße
Ascos
Hi,
ein blinkendes Antennensymbol bedeutet laut Manual eine Kommunikationsstörung zu einem Peering Partner. Bei virtuellen Sensor ist das das HM IO Device des FHEM Servers.
Wie sind denn die rssi Werte für dieses Thermostat?
Tobias
Gesendet von iPad mit Tapatalk
Hallo,
ich habe das nun auch implementiert und ein ähnliches Problem, Situation:
- Im WZ 3 Thermostate mit einem Lacrosse
- Im BZ 1 Thermostat mit einem Lacrosse
Alle 4 RTs nehmen (ab und zu) die gesendete Temperatur nicht an, bislang (es läuft seid Sonntag) sehe ich hier keinen Zusammenhang / Regelmäßigkeit.
Die RTs "fangen" sich nach einiger Zeit (Stunden / Minuten) wieder.
Die RSSIs liegen alle zwischen: -56 & -62 (Wohnzimmer) und bei -79 (Badezimmer)
Irgendwelche Ideen / Vorschläge?
ZitatIrgendwelche Ideen / Vorschläge?
raw-messages loggen. was für ein system hast du? io-device, fhem-server. gibt es disconnects? der bad-rssi ist nicht berauschend.
Hi,
danke für das schnelle Feedback:
System Rpi, mit USB LAN Adapter für HM & Jeelink für LaCrosse, zumindest im normalen Log sehe ich keine disconnects.
Ich bin am Freitag wieder zu Hause und werde mal:
- Placement des HM dongles optimieren um den Empfang zu verbessern
- Jeelink und HM dongle räumlich weiter trennen
- RSSIs loggen (vielleicht passiert da was)
- RAW loggen --> kann mir jmd einen hinweis geben was ich mir anschauen durchlesen muss (vorher) :)
Gruß
Zitat von: tpm88 am 09 Februar 2015, 23:11:35
Hi,
ein blinkendes Antennensymbol bedeutet laut Manual eine Kommunikationsstörung zu einem Peering Partner. Bei virtuellen Sensor ist das das HM IO Device des FHEM Servers.
Wie sind denn die rssi Werte für dieses Thermostat?
Tobias
Gesendet von iPad mit Tapatalk
Hi,
bitte entschuldige, ich war die letzten Tage viel arbeiten und habe deine Antwort nicht gesehen.
Inzwischen ist es bei allen 3 Thermostaten, das sie ab und zu über den Tag hinweg die Verbindung verlieren, zumindest was den Temperaturkanal angeht.
Die RSSI Werte
Schlafzimmer
rssi_HMLAN1 avg:-56.97 min:-64 max:-53 lst:-56 cnt:37
rssi_at_HMLAN1 avg:-59.08 min:-76 max:-54 lst:-61 cnt:2881Bad
rssi_HMLAN1 avg:-50.15 min:-53 max:-47 lst:-49 cnt:40
rssi_at_HMLAN1 avg:-53.48 min:-62 max:-51 lst:-53 cnt:2898Küche
rssi_HMLAN1 avg:-43.44 min:-52 max:-41 lst:-41 cnt:27
rssi_at_HMLAN1 avg:-47.1 min:-61 max:-45 lst:-45 cnt:2842Nach ca. 30 -90 Minuten haben sie sich dann wieder gefunden.
Ich bin für jede Hilfe dankbar.
Viele GRüße
Ascos
Hallo Ascos,
kurzzeitige Aussetzer (siehe meinen Beitrag weiter oben im Thread) oder auch aktuell hier (http://forum.fhem.de/index.php/topic,33631.msg260133.html#msg260133 (http://forum.fhem.de/index.php/topic,33631.msg260133.html#msg260133)) kommen immer mal vor. So lange wie bei dir (30 - 90 Minuten) sollte es aber keinesfalls sein.
Schwierig - mir fallen im Moment ein paar Sachen ein, wo man mit der Fehlersuche beginnen könnte:
- hast Du disconnects / reconnects des HMLAN im Log? Ich sehe immer wieder Threads im Forum, wo der HMLAN CFG nicht stabil läuft. Ich selbst nutze einen HM CFG USB2.
- Firmware der RT-DNs (mit der alten 1.0 hatte ich auch größere Probleme, mittlerweile unter 1.4 läuft es sehr stabil)
- hast Du eine vccu eingerichtet? Wenn nein, solltest Du das tun.
- hast Du mal mit apptime über einen vernünftigen Zeitraum (z.B. 30 - 60min) gemessen, ob Du auffällige Hänger des FHEM Servers beobachtest
- meldet der Action Detector in den Zeiträumen, wo die Temperaturen _nicht_ übertragen werden, Thermostate als missing?
- zeigt der HMinfo protoEvents Auffälligkeiten (Resends, NACK, etc.)
- FHEM auf neuestem Stand?
Wie ich auch in dem anderen Beitrag geschrieben habe, ist das Timing bei HomeMatic kritisch. Sehr sporadisch habe ich auch einmal einen kurzen Aussetzer, der aber immer nach dem nächsten Aufwachen des Thermostats (ca 3min später) wieder behoben ist.
Wenn obige Anregungen kein Problem ans Licht bringen, hilft nur Logging auf (raw) Paketebene. Dann müsstest Du Martin bitten, den raw Packet Trace zu analysieren.
Gruß
Tobias
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
Hallo Ascos,
kurzzeitige Aussetzer (siehe meinen Beitrag weiter oben im Thread) oder auch aktuell hier (http://forum.fhem.de/index.php/topic,33631.msg260133.html#msg260133 (http://forum.fhem.de/index.php/topic,33631.msg260133.html#msg260133)) kommen immer mal vor. So lange wie bei dir (30 - 90 Minuten) sollte es aber keinesfalls sein.
Hey,
das habe ich gelesen und beobachte es auch weiter. Heute früh war mein badezimmer genau 60 Minuten ohne Fühler.
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
Schwierig - mir fallen im Moment ein paar Sachen ein, wo man mit der Fehlersuche beginnen könnte:
- hast Du disconnects / reconnects des HMLAN im Log? Ich sehe immer wieder Threads im Forum, wo der HMLAN CFG nicht stabil läuft. Ich selbst nutze einen HM CFG USB2.
Gestern waren 3 disconnets, da könnte es dazu passen, aber heute lief alles stabil und da stieg mein Bad aus.
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
- Firmware der RT-DNs (mit der alten 1.0 hatte ich auch größere Probleme, mittlerweile unter 1.4 läuft es sehr stabil)
Habe eben nachgesehen, habe Firmware 1.3 drauf.
Für ein Update fehlt mir noch die Hardware.
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
- hast Du eine vccu eingerichtet? Wenn nein, solltest Du das tun.
Nein, bisher nicht. Mache ich heute Abend.
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
- hast Du mal mit apptime über einen vernünftigen Zeitraum (z.B. 30 - 60min) gemessen, ob Du auffällige Hänger des FHEM Servers beobachtest
Nein, noch nicht. Gucke ich mir heute Abend an, wenn ich zu Hause bin, und werde es dann testen.
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
- meldet der Action Detector in den Zeiträumen, wo die Temperaturen _nicht_ übertragen werden, Thermostate als missing?
Habe ich nicht drauf geachtet, werde ich aber das nächste Mal checken, wenn es wieder aussetzt. Habe nur gesehen, das ab und zu meine Fensterkontakte als dead angezeigt werden. Wenn ich sie dann aber benutze, funktionieren sie in Kombination mit meinen Thermostaten einwandfrei. Meist ist es dann auch nur ein Sendezyklus, beim nächsten ist es dann wieder normal.
Zitat von: tpm88 am 12 Februar 2015, 13:47:23
- zeigt der HMinfo protoEvents Auffälligkeiten (Resends, NACK, etc.)
protoEvents done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
Bad.Fenster : done | - |145: | - # - | - | - | -
Bad.Heizung : done | - |105: | - # - | - | - | -
Bad.VT : done | - |2787: | - # - | - | - | -
Kueche.Fenster : done | - |136: | - # - | - | - | -
Kueche.Heizung : done | - |73: | - # - | - | - | -
Kueche.VT : done | - |2780: | - # - | - | - | -
SZ.Fenster : done | - |122: | - # - | - | - | -
SZ.Heizung : done | - |87: | - # - | - | - | -
SZ.VT : done | - |2783: | - # - | - | - | -
WZ.Fenster : done | - |145: | - # - | - | - | -
WZ.Heizung : done | - |38: | - # - | - | - | -
WZ.Wandthermostat : done | - |140: |3: # - | - | - | -
================================================================================================================
sum 0 |0 |9341 |3 #0 |0 |0 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : none
status request :
autoReadReg wakeup :
status request wakeup:
autoReadTest :
IODevs:HMLAN1:opened pending=0 condition:ok
msgLoadEst: 1hour:3% 10min steps: 0/0/0/0/0/0 Zitat von: tpm88 am 12 Februar 2015, 13:47:23
- FHEM auf neuestem Stand?
Wurde letzte Woche aufgesetzt und da wurden alle updates installiert.
Eine Frage habe ich noch. Ich habe für die Lacrosse ja 3 virtuelle Sensoren. Wie kann ich es abstellen, das die mein Log zumüllen? Finde die Funktion nicht, wie ich deren updates aus meinem Log entfernen kann.
Vielen, vielen Dank auf jeden Fall für deine Hilfe.
Werde noch ein Update posten, sobald ich zu Hause bin und die fehlenden Dinge nachgeholt habe.
Viele Grüße
Ascos
Die VCCU habe ich eben eingerichtet.
Habe in den letzten 90 Minuten Apptime laufen lassen.
Ausgestiegen ist in der Zeit nichts, alles lief reibungslos. Vielleicht gibt es ja aber trotzdem Auffälligkeiten, die ihr seht:
name function max count total average maxDly
WZ.MediaPlayer XBMC_Ready 3008 6117 246763 40.34 0 HASH(WZ.MediaPlayer)
FileLog_Kueche FileLog_Get 1434 6 8303 1383.83 0 HASH(FileLog_Kueche); FileLog_Kueche; CURRENT; INT; 2015-02-11_18:30:00; 2015-02-12_18:30:01; 4:Kueche.Heizung.actuator\x3a::; 4:Kueche.Temp.humidity\x3a::; 4:Kueche.Heizung.desired-temp\x3a::; 4:Kueche.Heizung.measured-temp\x3a::
FileLog_Bad FileLog_Get 746 4 2887 721.75 0 HASH(FileLog_Bad); FileLog_Bad; CURRENT; INT; 2015-02-11_18:45:00; 2015-02-12_18:45:01; 4:Bad.Heizung.actuator\x3a::; 4:Bad.Temp.humidity\x3a::; 4:Bad.Heizung.desired-temp\x3a::; 4:Bad.Heizung.measured-temp\x3a::
FileLog_Schlafzimmer FileLog_Get 620 6 3460 576.67 0 HASH(FileLog_Schlafzimmer); FileLog_Schlafzimmer; CURRENT; INT; 2015-02-11_18:30:00; 2015-02-12_18:30:01; 4:SZ.Heizung.actuator\x3a::; 4:SZ.Temp.humidity\x3a::; 4:SZ.Heizung.desired-temp\x3a::; 4:SZ.Heizung.measured-temp\x3a::
HMLAN1 HMLAN_Read 391 521 22181 42.57 0 HASH(HMLAN1)
FileLog_Wohnzimmer FileLog_Get 280 5 1344 268.80 0 HASH(FileLog_Wohnzimmer); FileLog_Wohnzimmer; CURRENT; INT; 2015-02-11_19:15:00; 2015-02-12_19:15:01; 4:WZ.Heizung.actuator\x3a::; 4:WZ.Wandthermostat_Weather.humidity\x3a::; 4:WZ.Heizung.desired-temp\x3a::; 4:WZ.Wandthermostat_Weather.temperature\x3a::
tmr-CUL_HM_valvePosUpdt valvePos:11111201 202 34 2456 72.24 4544 valvePos:11111201
myJeeLink JeeLink_Read 152 2731 10841 3.97 0 HASH(myJeeLink)
FHEMWEB:192.168.178.21:57290 FW_Read 127 2 127 63.50 0 HASH(FHEMWEB:192.168.178.21:57290)
tmr-at_Exec HASH(0x12636b0) 115 43 1330 30.93 3013 HASH(at_Bad.VT)
tmr-at_Exec HASH(0x12ea000) 113 43 1322 30.74 8595 HASH(at_SZ.VT)
tmr-CUL_HM_ActCheck ActionDetector 107 8 291 36.38 35 ActionDetector
WZ.Wandthermostat_Climate CUL_HM_Set 94 40 659 16.48 0 HASH(WZ.Wandthermostat_Climate); WZ.Wandthermostat_Climate; desired-temp; 19.0
tmr-Heating_Control_Update HASH(0x18821f0) 81 1 81 81.00 5 HASH(HCWZ_Update)
vccu CUL_HM_Attr 79 3 108 36.00 0 set; vccu; model; CCU-FHEM
tmr-CUL_HM_valvePosUpdt valvePos:11111101 74 34 2283 67.15 3009 valvePos:11111101
HCWZ Heating_Control_Define 68 1 68 68.00 0 HASH(HCWZ); HCWZ Heating_Control WZ.Wandthermostat_Climate 12345|06:00|19 12345|10:00|18 67|08:00|19 67|10:00|19 16:00|19.5 21:00|19 12345|23:00|18 24:00|17 (ReadingsVal("HCAutomatik", "state", "") eq "on" && ReadingsVal("HZ.Absenkung", "state", "") eq "off")
tmr-at_Exec HASH(0x12e70d0) 59 43 1222 28.42 4536 HASH(at_Kueche.VT)
Bad.VT_Sensor1 CUL_HM_Set 58 48 778 16.21 0 HASH(Bad.VT_Sensor1); Bad.VT_Sensor1; virtTemp; 19.6
tmr-CUL_HM_updateConfig updateConfig 54 2 95 47.50 7 updateConfig
Kueche.VT_Sensor1 CUL_HM_Set 44 51 796 15.61 0 HASH(Kueche.VT_Sensor1); Kueche.VT_Sensor1; virtTemp; 17.1
VG
Ascos
Die filelogs kommen regelmaessig dran und brauchen .5 bis 1.3s im schnitt. Das kann gelegentlich zu problemen fuehren.
Eben ist mein Küchensensor wieder ausgestiegen
Hier noch Apptime, was noch weiter gelaufen ist:
name function max count total average maxDly
WZ.MediaPlayer XBMC_Ready 3008 6691 270806 40.47 0 HASH(WZ.MediaPlayer)
FHEMWEB:192.168.178.21:57364 FW_Read 1858 11 2390 217.27 0 HASH(FHEMWEB:192.168.178.21:57364)
FileLog_Kueche FileLog_Get 1434 6 8303 1383.83 0 HASH(FileLog_Kueche); FileLog_Kueche; CURRENT; INT; 2015-02-11_18:30:00; 2015-02-12_18:30:01; 4:Kueche.Heizung.actuator\x3a::; 4:Kueche.Temp.humidity\x3a::; 4:Kueche.Heizung.desired-temp\x3a::; 4:Kueche.Heizung.measured-temp\x3a::
FileLog_Bad FileLog_Get 746 4 2887 721.75 0 HASH(FileLog_Bad); FileLog_Bad; CURRENT; INT; 2015-02-11_18:45:00; 2015-02-12_18:45:01; 4:Bad.Heizung.actuator\x3a::; 4:Bad.Temp.humidity\x3a::; 4:Bad.Heizung.desired-temp\x3a::; 4:Bad.Heizung.measured-temp\x3a::
FileLog_Schlafzimmer FileLog_Get 620 6 3460 576.67 0 HASH(FileLog_Schlafzimmer); FileLog_Schlafzimmer; CURRENT; INT; 2015-02-11_18:30:00; 2015-02-12_18:30:01; 4:SZ.Heizung.actuator\x3a::; 4:SZ.Temp.humidity\x3a::; 4:SZ.Heizung.desired-temp\x3a::; 4:SZ.Heizung.measured-temp\x3a::
FHEMWEB:192.168.178.21:57358 FW_Read 472 15 609 40.60 0 HASH(FHEMWEB:192.168.178.21:57358)
HMLAN1 HMLAN_Read 391 612 27836 45.48 0 HASH(HMLAN1)
FileLog_Wohnzimmer FileLog_Get 280 5 1344 268.80 0 HASH(FileLog_Wohnzimmer); FileLog_Wohnzimmer; CURRENT; INT; 2015-02-11_19:15:00; 2015-02-12_19:15:01; 4:WZ.Heizung.actuator\x3a::; 4:WZ.Wandthermostat_Weather.humidity\x3a::; 4:WZ.Heizung.desired-temp\x3a::; 4:WZ.Wandthermostat_Weather.temperature\x3a::
tmr-CUL_HM_valvePosUpdt valvePos:11111201 202 38 2725 71.71 4544 valvePos:11111201
myJeeLink JeeLink_Read 152 2994 12143 4.06 0 HASH(myJeeLink)
tmr-CUL_HM_ActCheck ActionDetector 138 9 429 47.67 35 ActionDetector
tmr-at_Exec HASH(0x12636b0) 115 47 1443 30.70 3013 HASH(at_Bad.VT)
tmr-at_Exec HASH(0x12ea000) 113 48 1461 30.44 8595 HASH(at_SZ.VT)
tmr-at_Exec HASH(0x12e70d0) 103 48 1442 30.04 4536 HASH(at_Kueche.VT)
WZ.Wandthermostat_Climate CUL_HM_Set 94 47 745 15.85 0 HASH(WZ.Wandthermostat_Climate); WZ.Wandthermostat_Climate; desired-temp; 19.0
tmr-Heating_Control_Update HASH(0x18821f0) 81 1 81 81.00 5 HASH(HCWZ_Update)
vccu CUL_HM_Attr 79 3 108 36.00 0 set; vccu; model; CCU-FHEM
tmr-CUL_HM_valvePosUpdt valvePos:11111101 74 37 2489 67.27 3009 valvePos:11111101
HCWZ Heating_Control_Define 68 1 68 68.00 0 HASH(HCWZ); HCWZ Heating_Control WZ.Wandthermostat_Climate 12345|06:00|19 12345|10:00|18 67|08:00|19 67|10:00|19 16:00|19.5 21:00|19 12345|23:00|18 24:00|17 (ReadingsVal("HCAutomatik", "state", "") eq "on" && ReadingsVal("HZ.Absenkung", "state", "") eq "off")
Bad.VT_Sensor1 CUL_HM_Set 58 52 836 16.08 0 HASH(Bad.VT_Sensor1); Bad.VT_Sensor1; virtTemp; 19.6
Kueche.VT_Sensor1 CUL_HM_Set 58 56 916 16.36 0 HASH(Kueche.VT_Sensor1); Kueche.VT_Sensor1; virtTemp; 17Sieht eigentlich nicht viel anders aus, als der andere Auszug aus Apptime
Zitat von: martinp876 am 12 Februar 2015, 19:57:42
Die filelogs kommen regelmaessig dran und brauchen .5 bis 1.3s im schnitt. Das kann gelegentlich zu problemen fuehren.
Habe ich auch gesehen. Wie kann ich das ändern? Habe schon "event-on-change-reading" definiert um die Anzahl der Logeinträge zu reduzieren.
Einzig die virtuellen Sensoren erzeugen im normalen Logfile noch sehr viele einträge. Wie kann ich das abschalten? Habe da leider trotz langer Suche noch nichts gefunden.
VG
Ascos
Hey,
Möchte kurz berichten.
Habe nun eine vccu eingerichtet, die Position des HMLan verändert, meine Logs massiv reduziert und seit dem geht es. Habe zwar 1-2x am Tag, das die Semsoren kurz weg sind, aber dann finden Sie sich beim nächsten Mal wieder.
Der usb Stick für die Firmware updates ist auch bestellt.
Ich beobachte weiter, aber ich bin zuversichtlich.
Vielen Dank für eure Hilfe.
VG
Ascos
Hallo,
auch von mir kurzes Feedback:
- neue location des Senders fixt das Problem zu 90% bei mir
- VCCU muss ich noch einrichten
--> DANKE
Hallo,
Kurze Frage meinerseits:
Muss ich für jedes thermomether ein eigenes virtuelles Device anlegen oder kann man das eleganter lösen?
Gruß
Sparky
Hab ein ähnliches Problem mit LaCrosse Sensoren. Die Virtuellen Kanäle Stammen aus der VCCU und werden auch gesetzt und sind gepeerd aber leider wird im Wetter-Kanal von den HM-CC-RT-DN nichts übernommen. Benutzt werden weiterhin die Werte aus dem internen Sensor.
Ich habe das seinerzeit mit einem virtuellen Device mit mehreren Kanälen probiert; das hat bei mir aber nicht geklappt. Ich bekam die nicht unabhängig gesetzt.
Daher habe ich jeweils ein eigenes virtuelles Device angelegt.
Im Nachhinein habe ich die Vermutung, dass es an der Wertzuweisung lag; nachdem ich die at's dafür per align time versetzt habe, läuft das zuverlässig.
Nach dem Peeren restarten und warten, ich war zu ungeduldig.
Die VCCU habe ich erst später angelegt; da habe ich im Hinterkopf, dass die virtuellen Kanäle der VCCU keine temp unterstützen.
Wenn das mittlerweile alles geht, ware das natürlich einfacher...
einfach entsprechend viele virtuelle Kanäle in der VCCU konfigurieren und los geht es.
Ob das mittlerweile geht weiß ich nicht. allerdings hab ich auch schon extra ein virtuelles Device angelegt dort Kanäle erstellt und neu mit diesen gepeert. Funktioniert genau sowenig.
Wie sieht der virtuelle aktor aus?
Sendet der regelmäßig?
Zitat von: kleinerDrache am 22 September 2015, 05:26:54
...hab ich auch schon extra ein virtuelles Device angelegt dort Kanäle erstellt und neu mit diesen gepeert. Funktioniert genau sowenig.
Wie wäre es mal mit ein paar Codezeilen für virtuellen Aktor und at ? ;)
Wird im Log etwas angezeigt?
Mit 1 virtuellen Device und mehreren Kanälen hat es (wie ich extra geschrieben habe) bei mir auch nicht funktioniert.
Ich weiss aber nicht warum das so ist/war. :-[
eingerichtet nach Wiki
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren (http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Temperatursensoren)
keinerlei meldungen im Log ausser das setzen der temp im at.
Zitat von: kleinerDrache am 22 September 2015, 16:11:59
eingerichtet nach Wiki...
Das kann ja alles sein, aber möglicherweise hat ja der ein odere andere Schritt nicht so funktioniert, wie es vom Wiki-Verfasser vorgesehen war. Gib mal den Kollegen die Chance, Dir zu helfen und stelle folgendes hier zur Verfügung:
1. Die entsprechenden Abschnitte in der fhem.cfg
2. Ein "list" von allen beteilgten Devices und Kanälen, ob nun virtuell oder nicht.
3. Ein Level-5-Log über ein paar Minuten.
Gruß,
Thorsten
ok ok nicht gleich erschießen ;)
Infos kommen sobald ich zeit hab:
fhem.cfg hab ich nicht, Stichwort Configdb, aber wenn mir einer sagt wie ich da bestimmte teile raus posten kann mach ich das gerne.
Der Rest dauert etwas, musste alles neu einrichten. Hab mir mit dem 30 cm Bug alles zerlegt aber wenn ich wieder soweit bin auch das gerne.
Eventuell iss ja auch alles tutti wenn ich fertig bin dann lag es auch am 30 cm Bug.
Edit:
Ok war anscheinend doch der 30 cm Bug. Hab alles wieder fertig und läuft im moment mit 3 x HM-CC-RT-DN und einem Intertechno Sensor pro RT. Mal ein paar Tage beobachten ob das auch stabiel bleibt.
Hallo,
Ich habe meine Lacrosse Temperatursensoren (2 Stück) über virtuelle Temperatursensoren jeweils mit 2 Homematic Heizunsventilen HM-CC-RT-DN gepeert laut der Anweisungen in diesem Beitrag.
Ich habe aber das Problem dass die gemessene Temperaturen nicht immer korrekt an dem entsprechenden Ventil ankommen, manchmal vertauscht, manchmal der gleiche Wert auf beiden Ventilen ?
Hier meine Konfiguration:
####### VCCU
define CCU CUL_HM 424242
attr CCU IODev hmusb
attr CCU IOList hmusb
attr CCU model CCU-FHEM
attr CCU msgRepeat 0
attr CCU subType virtual
attr CCU webCmd virtual:update
# Virtueller Temperatursensor OG.szcd
define OG.szcd.VT_Sensor CUL_HM 42424201
attr OG.szcd.VT_Sensor model CCU-FHEM
attr OG.szcd.VT_Sensor peerIDs 37F95A01,
attr OG.szcd.VT_Sensor webCmd virtTemp:virtHum
# Virtueller Temperatursensor OG.szsa
define OG.szsa.VT_Sensor CUL_HM 42424202
attr OG.szsa.VT_Sensor model CCU-FHEM
attr OG.szsa.VT_Sensor peerIDs 37EE7401,
attr OG.szsa.VT_Sensor webCmd virtTemp:virtHum
# Temperaturfühler 1
define OG.szcd.TF.Thermo LaCrosse 25
attr OG.szcd.TF.Thermo IODev myJeeLink
define at_OG.szcd.VT_Sensor at +*00:02 { my $T=(ReadingsVal("OG.szcd.TF.Thermo","temperature",19.9));; fhem ("set OG.szcd.VT_Sensor virtTemp $T") }
# Heizungsventil 1
define OG.szcd.HZ.Heizung_Weather CUL_HM 37F95A01
attr OG.szcd.HZ.Heizung_Weather model HM-CC-RT-DN
set OG.szcd.VT_Sensor peerChan 0 OG.szcd.HZ.Heizung_Weather single set
set hm peerXref
OG.szcd.HZ.Heizung_Weather => OG.szcd.VT_Sensor
OG.szcd.VT_Sensor => OG.szcd.HZ.Heizung_Weather
# Temperaturfühler 2
define OG.szsa.TF.Thermo LaCrosse 1D
attr OG.szsa.TF.Thermo IODev myJeeLink
define at_OG.szsa.VT_Sensor at +*00:02 { my $T=(ReadingsVal("OG.szsa.TF.Thermo","temperature",19.9));; fhem ("set OG.szsa.VT_Sensor virtTemp $T") }
# Heizungsventil 2
define OG.szsa.HZ.Heizung_Weather CUL_HM 37EE7401
attr OG.szsa.HZ.Heizung_Weather model HM-CC-RT-DN
set OG.szsa.VT_Sensor peerChan 0 OG.szsa.HZ.Heizung_Weather single set
set hm peerXref
OG.szsa.HZ.Heizung_Weather => OG.szsa.VT_Sensor
OG.szsa.VT_Sensor => OG.szsa.HZ.Heizung_Weather
list OG.szcd.VT_Sensor
Internals:
DEF 42424201
NAME OG.szcd.VT_Sensor
NR 63
STATE set_virtTemp 19.6
TYPE CUL_HM
chanNo 01
device CCU
peerList OG.szcd.HZ.Heizung_Weather,
Readings:
2015-10-04 09:51:21 humidity 0
2015-10-16 08:17:17 peerList OG.szcd.HZ.Heizung_Weather,
2015-10-19 20:50:57 state set_virtTemp 19.6
2015-10-19 20:50:57 temperature 19.6
Helper:
fkt virtThSens
virtTC 00
Role:
chn 1
Vd:
ackT
cmd 8670424242000000
idh 1325082
idl 16896
miss 0
msgCnt 211
msgRed 0
next 1445280771.4901
nextM 1445280771.4901
typ 2
val 00C4
vin 19.6
Attributes:
model CCU-FHEM
peerIDs 37F95A01,
webCmd virtTemp:virtHum
list OG.szsa.VT_Sensor
Internals:
DEF 42424202
NAME OG.szsa.VT_Sensor
NR 66
STATE set_virtTemp 20.3
TYPE CUL_HM
chanNo 02
device CCU
peerList OG.szsa.HZ.Heizung_Weather,
Readings:
2015-10-13 19:35:38 humidity 0
2015-10-16 08:17:17 peerList OG.szsa.HZ.Heizung_Weather,
2015-10-19 20:52:57 state set_virtTemp 20.3
2015-10-19 20:52:57 temperature 20.3
Helper:
fkt virtThSens
virtTC 00
Role:
chn 1
Vd:
ackT
cmd 8670424242000000
idh 1325082
idl 16896
miss 0
msgCnt 211
msgRed 0
next 1445280829.98691
nextM 1445280829.98691
typ 2
val 00CB
vin 20.3
Attributes:
model CCU-FHEM
peerIDs 37EE7401,
webCmd virtTemp:virtHum
Ich dachte die virtuellen Kanäle der vccu können kein temp !? ???
Du hast auch nicht 2 virtuelle Devices erstellt, sondern 2 Kanäle in 1 Device.
Das scheint teilweise problematisch zu sein; zumindest habe ich es damit seinerzeit nicht vernünftig ans Rennen bekommen.
P.S.:
Trotz "monatelanger" korrekter Funktion springen die Temp-Werte bei mir momentan auch etwas.
Ich konnte nur noch nicht eingrenzen, woran es liegt: Tempsensor, Jeelink-Clone, virt. Device, at, Heizkörperthermostat. :-\
Das heisst pro temperturfühler eine vccu=1 device?
Habe 10 temperaturfühler, dann müsste ich 10 vccu definieren anstelle von 10 Kanälen,
Ergibt dies keine anderen Nachteile für den Fhem-server?
Nur virtuelle Homematic-Devices mit je einem Kanal, nicht mehrere vccu.
Also so wie das hier im Forum und im Wiki beschrieben ist.
Die vccu ist ja als"Sammler und Verwalter" für IODevs.
siehe hier: http://forum.fhem.de/index.php/topic,42109.0.html (http://forum.fhem.de/index.php/topic,42109.0.html)
Du kannst auch das Kommando postevent probieren.
Ja, ich hatte auch Probleme beim Peeren eines Devices mit vccu Channel. Dem Device passte die Nummer des Channels nicht. Dann habe ich ein vd mit einem Channel angelegt und es lief.
Gibt es eigentlich eine Möglichkeit die Einträge im Logfile alle 2 Minuten für die virtuellen Sensor abzuschalten?
Ich habe gesucht und dazu leider nichts gefunden.
Welche Einträge?
Sent from my iPhone using Tapatalk
Diese hier:
2015.10.21 06:44:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.3
2015.10.21 06:46:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.3
2015.10.21 06:48:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.3
2015.10.21 06:50:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.3
2015.10.21 06:52:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.2
2015.10.21 06:54:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.2
2015.10.21 06:56:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.3
2015.10.21 06:58:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.2
2015.10.21 07:00:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.2
2015.10.21 07:02:11 3: CUL_HM set Bad_vT_Sensor1 virtTemp 19.2
Da ich nächste Woche den restlichen Teil meiner Wohnung mit HM-CC-RT-DN ausrüsten will, müllen mir diese Einträge ja das logfile zu, mit etwas was ich gar nicht benötigte.
Dann würde ich erstmal auf event_on_change gehen, dann sind die unveränderten raus.
Sent from my iPhone using Tapatalk
Setz die virtuellen Devices für die Tempsensoren auf verbose 2 ; dann hast Du im Log Ruhe. :)
Zitat von: volschin am 21 Oktober 2015, 09:42:15
Dann würde ich erstmal auf event_on_change gehen, dann sind die unveränderten raus.
Das hatte ich im Vorfeld schon probiert, hat leider nicht funktioniert. Es wurden immer noch alle Werte geschrieben. Trotzdem Danke für die Hilfe.
Zitat von: Hollo am 21 Oktober 2015, 09:48:55
Setz die virtuellen Devices für die Tempsensoren auf verbose 2 ; dann hast Du im Log Ruhe. :)
Das hat endlich geholfen. Danke schön.
Ich benutze jetzt für jeden Temperaturfühler ein Homematic-Device mit einem Kanal.
Das funktionniert auch meistens aber leider nicht immer d.h. im virtuellen device ist die
gemessene Temperatur richtig doch leider nicht am Heitungsthermostat aber irgendwann
stimmts diese dann wieder. Hat irgendeienr ne Idee oder das gleiche Problem ?
Zitat von: deckelsmouk am 29 Oktober 2015, 11:40:08
Ich benutze jetzt für jeden Temperaturfühler ein Homematic-Device mit einem Kanal.
Das funktionniert auch meistens aber leider nicht immer d.h. im virtuellen device ist die
gemessene Temperatur richtig doch leider nicht am Heitungsthermostat aber irgendwann
stimmts diese dann wieder. Hat irgendeienr ne Idee oder das gleiche Problem ?
Ich hatte mal etwas ähnliches am Laufen und zumindest dieser Teil hat gut funktioniert. Hast Du mal nachgeschaut, ob der RT sonst auch Verbindungsprobleme mit FHEM hat?
wie sieht es denn mit freezes/verzögerungen in fhem aus? wenn du im wakeup-mode arbeitest, ist das timing entscheidend.
schon mal apptime und perfmon angeschaut?
Habe das ganze jetzt mal eine Zeit lang beobachtet.
Perfmon hat kein Problem gemeldet.
Apptime ergibt folgendes:
name function max count total average maxDly
tmr-at_Exec HASH(0x27784b0) 108 5 520 104.00 4 HASH(at_OG.szcd.VT_Sensor)
tmr-at_Exec HASH(0x2555c78) 103 5 504 100.80 23 HASH(at_OG.szsa.VT_Sensor)
tmr-at_Exec HASH(0x27ca1b0) 99 5 494 98.80 59 HASH(at_OG.at.VT_Sensor)
myJeeLink JeeLink_Read 90 388 6831 17.61 0 HASH(myJeeLink)
OG.szcd.VT_Sensor CUL_HM_Set 62 5 296 59.20 0 HASH(OG.szcd.VT_Sensor); OG.szcd.VT_Sensor; virtTemp; 19.4
OG.szsa.VT_Sensor CUL_HM_Set 59 5 279 55.80 0 HASH(OG.szsa.VT_Sensor); OG.szsa.VT_Sensor; virtTemp; 19.2
OG.at.VT_Sensor CUL_HM_Set 56 5 278 55.60 0 HASH(OG.at.VT_Sensor); OG.at.VT_Sensor; virtTemp; 20.4
Von den 3 Sensoren wurden auf 2 Ventilen die Werte korrekt übernommen und auf dem dritten (OG.at.VT_Sensor) hat es über eine Stunde gedauert bis
die richtige Temperatur gesendet wurde ?
Hallo Zusammen,
ich habe seit längerem einen Tempfühler laufen, der über ein virtuelles Device an zwei HM Thermostate gepeere ist.
funktioniert auch perfekt.
Jetzt habe ich dem virtuellen Device noch einen Channel gegeben, um in einem anderen Raum auch einen Tempfühler mit einem HM Theromstat zu peeren.
Kann es sein, dass das so nicht geht und ich nicht mehrere Channels verwenden kann?
Im Moment bekommen wohl alle Thermostate die Temperatur über den Channel 2 mitgeteilt, obwohl das Peering stimmt.
Hier noch die Devices:
Internals:
DEF 221144
IODev HMLan
NAME vTemp
NR 613
NTFY_ORDER 50-vTemp
STATE CMDs_done
TYPE CUL_HM
channel_01 vTemp_Sensor_Flur
channel_02 vTemp_Sensor_Buero
protSnd 74 last_at:2015-11-03 13:49:32
protState CMDs_done
Readings:
2015-10-29 13:53:07 .protLastRcv 2015-10-29 13:53:07
2015-11-03 13:49:32 state CMDs_done
Helper:
HM_CMDNR 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
vccu VCCU
Mrssi:
mNo
Io:
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
vrt 1
Rssi:
Shadowreg:
Attributes:
IODev HMLan
IOgrp VCCU
expert 2_full
group virtual
model virtual_2
msgRepeat 0
room Unsorted
subType virtual
webCmd virtual
Internals:
.triggerUsed 1
DEF 22114401
NAME vTemp_Sensor_Flur
NR 614
NTFY_ORDER 50-vTemp_Sensor_Flur
STATE set_virtTemp 21.4
TYPE CUL_HM
chanNo 01
device vTemp
peerList HZ_Flur_oben_Weather,HZ_Flur_unten_Weather,
CHANGETIME:
Helper:
Dblog:
Temperature:
Mydblog:
TIME 1446555155.67127
VALUE 21.4
Readings:
2015-11-03 12:17:43 peerList HZ_Flur_oben_Weather,HZ_Flur_unten_Weather,
2015-11-03 13:52:35 state set_virtTemp 21.4
2015-11-03 13:52:35 temperature 21.4
Helper:
fkt virtThSens
virtTC 00
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
vrt 1
Shadowreg:
Vd:
cmd 8670221144000000
idh 341309
idl 17408
msgCnt 38
msgRed 0
next 1446555291.37106
nextM 1446555291.37106
typ 2
val 00D6
vin 21.4
Attributes:
group virtual
model virtual_1
peerIDs 2E63BE01,2E673001,
room Unsorted
verbose 0
webCmd press short:press long
Internals:
.triggerUsed 1
DEF 22114402
NAME vTemp_Sensor_Buero
NR 617
NTFY_ORDER 50-vTemp_Sensor_Buero
STATE set_virtTemp 21.5
TYPE CUL_HM
chanNo 02
device vTemp
peerList HZ_Buero_Weather,
CHANGETIME:
Helper:
Dblog:
Temperature:
Mydblog:
TIME 1446555100.8309
VALUE 21.5
Readings:
2015-11-03 12:55:27 peerList HZ_Buero_Weather,
2015-11-03 13:51:40 state set_virtTemp 21.5
2015-11-03 13:51:40 temperature 21.5
Helper:
fkt virtThSens
virtTC 00
Expert:
def 1
det 0
raw 1
tpl 0
Role:
chn 1
vrt 1
Shadowreg:
Vd:
cmd 8670221144000000
idh 341309
idl 17408
msgCnt 38
msgRed 0
next 1446555290.81004
nextM 1446555290.81004
typ 2
val 00D7
vin 21.5
Attributes:
group virtual
model virtual_2
peerIDs 2EA21D01,
room Unsorted
verbose 0
webCmd press short:press long
Zitat von: Mitch am 03 November 2015, 13:53:30
...Kann es sein, dass das so nicht geht und ich nicht mehrere Channels verwenden kann?
...
Korrekt. Die Thermostate gucken in dem Fall wohl nur auf das gepeerte Device und ignorieren unterschiedliche Channel.
Ich habe es zumindest mit 1 virt. Device und 2 Kanälen nicht hinbekommen bzw. ähnliche Probleme wie Du gehabt.
Wobei ja der Channel gepeered ist und nicht das Device? ???
Werde jetzt mal noch ein virtuelles Device anlegen und testen.
Hi,
kann ich die Geschichte so lösen, dass nicht ein at stur Befehle sendet, sondern der Wert des virtuellen Temperatursensors nur geändert wird, wenn sich die Temperatur ändert?
Danke!
Stefan
Das mache ich so, hat aber auch nicht mit mehreren Channels funktioniert.
Zitat von: Mitch am 05 November 2015, 14:05:22
Das mache ich so, hat aber auch nicht mit mehreren Channels funktioniert.
War das die Antwort auf meine Frage? Wenn ja, wie hast du das gemacht?
Den at brauchst Du schon noch, allerdings trigger ich damit eine Routine aus meiner 99_myUtils:
sub tempFlur2HM() {
my $Tist=ReadingsVal("NC_WS_23_0","temperature",20.0);
my $Tsoll=ReadingsVal("vTemp_Sensor_Flur","temperature",20.0);
if($Tist ne $Tsoll) {
fhem("set vTemp_Sensor_Flur virtTemp $Tist")
}
}
Ahhh, sehr schlau! Danke dir!
Der Sinn erschliesßt sich mir trotzdem nicht. ???
Der externe Fühler ermittelt die IST-Temperatur und die soll auch als IST-Temp an den Thermostaten weitergegeben werden.
Ob die der SOLL-Temp entspricht ist doch für diese Kette total uninteressant, das soll ja am Ende das Thermostat regeln.
Da gab's eine kleine Vewirrung. Ich möchte ja die IST-Temperartur nur senden, wenn sie sich geändert hat und nicht einfach alle zwei Minuten. Sogesehen ist das Beispiel von Mitch für mich nicht ganz passend, läßt sich aber leicht umbauen.
Zitat von: Hollo am 06 November 2015, 09:13:10
Der Sinn erschliesßt sich mir trotzdem nicht. ???
Der externe Fühler ermittelt die IST-Temperatur und die soll auch als IST-Temp an den Thermostaten weitergegeben werden.
Ob die der SOLL-Temp entspricht ist doch für diese Kette total uninteressant, das soll ja am Ende das Thermostat regeln.
Das "Problem" ist, dass die Thermostate ohne externen Fühler total "übersteuern".
z.B. ist Soll 21 Grad, gemessen ist aber schon 23 Grad, trotzdem steht das Ventil auf 80%.
Ist wohl bei HM normal und wurde schon öfter diskutiert.
Mit einem externen Fühler, entweder HM Wandthermostat, oder irgend ein "Fremdfühler", kann man das "Problem" eliminieren.
In einem Scriptbeispiel ist IST der Wert, den der Fühler misst und der SOLL der Wert, der im virtuellen Sensor steht und übermittelt wird.
Die wird alle 5 Minuten mit at gecheckt, der neue Wert aber nur geschrieben, wenn er ein anderer ist.
Ich hoffe, dass im Peering auch nur der Wert an das Thermostat übermittelt wird, wenn er sich geändert hat, um nicht so viel zu senden.
Also Weg ist ja: Fühler -> virtueller HM Sensor -> Thermostat
Falls das Thermostat sowieso alle 5 Minuten "befeuert" wird, egal welcher Wert, dann kann man sich das sparen ;)
Zitat von: Mitch am 06 November 2015, 10:02:16
...In einem Scriptbeispiel ist IST der Wert, den der Fühler misst und der SOLL der Wert, der im virtuellen Sensor steht und übermittelt wird.
Die wird alle 5 Minuten mit at gecheckt, der neue Wert aber nur geschrieben, wenn er ein anderer ist...
Jetzt ist der Groschen (bin schon älter) gefallen. ;D
Bei mir wird per at der Wert des Sensors (IST) per "set blabla virtTemp" in den virtuellen Sensor geschrieben (SOLL); unabhängig von einer Temp-Änderung.
Du rufst per at Deine Funktion auf, und schreibst die Temp nur bei Veränderung!?
Ich denke mal, dass das egal ist, weil der Thermostat ja mittels Peering mit dem virtuellen Device kommuniziert; der Wert der Temperatur spielt dabei keine Rolle.
Diese Kette funktioniert meiner Meinung nach immer korrekt; auf beiden Wegen.
Die Frage ist, warum der Thermostat manchmal nicht mit dieser Temp arbeitet und stattdessen die interne (zu hohe) Temp nimmt...
Eigentlich gibt es ja nur 2 Möglichkeiten: Empfangs- oder Timing-Problem; die Antwort wäre evtl. der Weg zur Lösung. :-[
Hallo zusammen,
ich versuch mich auch gerade an der Inbetriebnahme der HM-CC-RT-DN. Ich will die Ist Temperatur auch mit den Lacrosse messen und an ein virtuelles Device schicken. Das funktioniert soweit auch ganz gut. Das peering wird mir mit "set hm peerXref" auch in beide Richtungen angezeigt. Der Lacrosse schreibt alle minuten den Wert ins virtuelle Device, aber im Weather Channel bzw. im Thermostat kann ich nichts davon sehen. Und es tut sich an dem Thermostat nichts. Das heißt das Thermostat reagiert nicht und in den Readings steht auch immer die measured temp des thermostat. Jetzt hab ich zwei Fragen, wie muss ich den Modus am Thermostat einstellen bzw. ist das egal? bzw. an welchen Variablen kann ich sehen, wie das Ventil arbeitet oder mit welcher gemessenen Zeit das Thermostat arbeitet? in diesem Artikel http://www.meintechblog.de/2013/10/neue-thermostate-von-homematic-high-end-heizungssteuerung-zum-kleinen-preis-mit-fhem/#more-3488 wird auf einen Actuator in % angezeigt, aber ich kann nichts finden.
Hallo zusammen, bei mir hat es jetzt funktioniert. Ein "get hm configCheck" hat gezeigt, dass das peering nicht richtig funktioniert hatte. Danach hab ich mit peerBulk öfters die Verbindung vom Weather Channel zum virtuellen Device eingestellt. Irgendwann hat es dann funktioniert. Vielen Dank für das Forum.
Zitat von: tpm88 am 21 Dezember 2014, 22:50:56
das funktioniert bei mir einwandfrei. Hier nochmal Schritt für Schritt:
1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>
2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1
3. Bei uns ist es kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1
4. Virtuellen Peer Sensor mit dem Weather Channel deines RT-DN peeren:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single
5. Peering kontrollieren (Voraussetzung: Device hm vom Type hmInfo existiert):
set hm peerXref
Beispiel-Ausgabe bei mir:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather
6. Gemessene Temperatur vom 1w DS1820 dem virtuellen HM Sensor übergeben. Ich mache das alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }
Fertig.
Wenn es bei dir klemmt, poste doch mal die Ausgaben von:
list <dein_virtuelles_HM_Device>
list <dein_virtueller_temperatur_Sensor>
list <dein_RT_DN>_Weather
Gruß
Tobi
Hallo wie muss ich vorgehen wenn ich 2 Thermostat habe. Irgendwie übergibt er die Temperatur immer nur an eins. Danke
für jeden rt ein eigenen virtuellen tempfühler und beide mit der temp füttern.
Zitat von: Hollo am 21 Oktober 2015, 09:48:55
Setz die virtuellen Devices für die Tempsensoren auf verbose 2 ; dann hast Du im Log Ruhe. :)
Zitat von: Steiner0815 am 21 Oktober 2015, 11:09:24
Zitat von: Hollo am 21 Oktober 2015, 09:48:55
Setz die virtuellen Devices für die Tempsensoren auf verbose 2 ; dann hast Du im Log Ruhe. :)
Das hat endlich geholfen. Danke schön.
Servus,
ich wollte die Logeinträge auch weg haben, aber der Tip hat bei mir nicht funktioniert. Die Einträge tauchten weiterhin im Logfile auf. Ich musste dem Kanal 1 in den virtuellen Devices das Attribut Verbose 2 setzen damit Ruhe einkehrte. Nur als Anmerkung falls wieder mal jemand darüber stolpert ...
MfG
Marco
Hallo zusammen,
ich bekomme das peering einfach nicht hin.
Die Temperatur des LaCrosse wird in den virtuellen Sensor eingetragen.
Aber das Peering mit dem HM-CC-RT-DN klappt nicht.
configCheck done:
peer not verified. Check that peer is set on both sides
virtual_temp_kz_Sensor1 p:Kinderzimmer_Heizung_Weather
PairedTo missing/unknown
virtual_temp
-----
peerXref done:
x-ref list
virtual_temp_kz_Sensor1 => Kinderzimmer_Heizung_Weather
Ich weiß mir leider selbst keinen Rat mehr.
Viele GRüße
Jay
EDIT: Ich habe alles noch einmal gelöscht und von vorne angefangen. Dann hat es geklappt. Hat sich also erledigt.
Hallo,
ich hoffe mir kann von euch jemand helfen.
Ich habe versucht nach der Anleitung das virtuelle Thermostat zu erstellen.
Das hat auch alles funktioniert. Allein beim peeren wird immer nur eine Richtung angelegt. Der Rückkanal vom HM_Weather zum virtuellen Thermostat wird nie angelegt.
Habt ihr ne Idee, was ich falsch mache? Das Befüllen von der Netatmo zum virtuellen Thermostat funktioniert auch. Nur das setzen des Wertes in dem HM_Weather funktioniert nicht.
Danke und viele Grüße.
Hallo Gruvol,
schau dir mal diesen Beitrag an: https://forum.fhem.de/index.php/topic,32402.msg249514.html#msg249514 (https://forum.fhem.de/index.php/topic,32402.msg249514.html#msg249514)
Da hab ich das Peering noch detaillierter beschrieben. Wenn es damit (immer) noch nicht klappt, poste mal die Ausgaben der einzelnen Schritte.
Gruß
Tobias
Hallo,
vielen Dank.
Das hat mir sehr geholfen und im Endeffekt geht es nun auch.
Dafür schon mal vielen Dank!
Habt ihr das auch, dass manchmal auf dem Thermostat das Antennensymbol blinkt und das Thermostat nicht mehr die Temperatur des virtuellen Thermostats annimmt? Kann man dagegen etwas machen?
Ich habe schon oft gelesen, dass sich manchmal die beiden Ist-Temperaturen vom Gerät und dem virtuellen überschneiden. Das kommt dann als nächstes dran :).
Viele Grüße
Hallo,
ich hätte da noch einmal eine Frage. Ich habe in einem Thread gelesen gehabt, dass man die Einträge für die Änderung des virtuellen Sensor im Log deaktivieren kann, sodass nicht mehr die ganzen Temperaturänderungen im Log zu sehen sind.
Kann mir einer von euch sagen, wie man das macht?
Vielen Dank und liebe Grüße.
setz mal im Virtuellen Sensor das Attribute "verbose" auf 0
Ah, genau danke, das war es :).
Hallo, kann mir jemand sagen was man noch so schönes mit diesen Virtuellen Fehlern machen kann?
Bei mir zeigt er seit einiger zeit auch Humidity an.
Was kann man mit press Short/Long bewirken?
So, da das ganze schon länger bei mir mit einem Netatmo Thermometer läuft, habe ich jetzt noch eine frage die immer mal wieder auftritt.
Z.b. Rasperry steigt aus. Sohn zieht Stromversorgung von Tehermometer. Sonstiges.
Beim ausfall heizt er si lange bis irgendwann mal wieder die Temperatur bekommt. Manchmal wudert es much dann warum es zu kalt oder zu warm ist.
Kann mann sa irgendwas machen, wenn er zum Beispiel keine Temp bekommt das die internen Regler solage übernehmen?
Hallo zusammen,
ich habe auch eine ganze weile daran gesessen bis es geklappt hat die VCCU-Channel mit Heizkörperthermostaten zu paieren.
Mein Lösungsweg:
Das Heizkörperthermostat von FHEM unpairen.
Als erstes das Thermostat mit einem ggf. vorhandenen Fensterkontakt pairen.
Dann das pairing mit FHEM direkt über das entsprechende IO-Device mit FHEM pairen, bei mir ist das ein HM_UART.
Danach bin ich der Anleitung gefolgt. Dabei sollte man nicht zu ungeduldig sein und solange warten bis aus "cmd_pending" wieder "cmd_done" geworden ist.
Bei mir schien das Problem darin bestanden zu haben, dass das Thermostat vorher direkt mit der VCCU gepairt war. Ist aber nur eine Vermutung.
Ist es nun im nachhinein möglich das Thermostat wieder der VCCU zuzuweisen, da es ja sinnvoller ist diese als IO-Device zu benutzen.
Die Frage von Badflex stellt sich mir auch. Wie verhindere ich bei einer Fehlfunktion, dass der Heizkörper weiter heizt, obwohl die Solltemperatur schon erreicht, nur halt nicht korrekt übermittelt worden ist.
Wäre es denkbar dafür ein DOIF zu schreiben? Entweder wird die Dauer gemessen in der es keine Temperaturänderung gab und dann wird sozusagen als Sicherheitsschaltung nach 15 Minuten eine Sollwerttemperatur von 18 Grad eingestellt. Außerdem könnte man die korrekte Übermittlung der Temperatur mit dem DOIF prüfen, indem die Temperatur des Sensors mit der in "_weather" im Thermostat verglichen wird. Weichen beide um mehr als 1°C ab werden bei "desired_temp" 18°C eingestellt.
Wäre das möglich?
Mein Problem ist aber noch ein anderes. Ich habe zwei Channel in der VCCU angelegt. Einen für das Bad (1) und einen für das Wohnzimmer (2). Nun ist es bei mir aus unerfindlichen Gründen passiert, dass das Thermostat welches mit chanNo (2) gepairt worden ist, eigenständig den chanNo auf (1) gewechselt hat. Er hat zwar noch den richtigen VCCU-Channel-Namen, hat nun aber die Termperatur aus dem Bad (1).
Hat jemand dafür eine Erklärung?
Mit einer VCCU wird eigentlich nie etwas gepairt. Genau so, wie nie etwas mit einem IODev gepairt wird. Es wird immer mit einer Zentrale gepairt, was eigentlich "nur" heißt, dass die HMID in das Device geschrieben wird, damit das Gerät weißt, mit welcher Zentrale es kommunizieren darf.
Es ist also völig egal, über was du das Pairing veranlasst, so lange du die selbe HMID verwendest, geht es mit oder ohne CCU und dann auch mit jedem weitern IODev, das du deiner Installation mit der selben HMID hinzufügst.
Achso, ok.
Weiß jemand wie ich die Temperatursensoren, bzw. den Channel der VCCU, welcher mit dem "_weather"-Channel der Thermostate gepairt ist wieder sauber unpaire? Oder muss ich die Homematic-Heizungsthermostate dafür reseten? In der Bedienungsanleitung steht zwar, dass es einen unpair-Punkt im Menü der Geräte geben soll, aber der taucht bei mir nicht auf. Ich kann sie nur reseten.
Die Radiatoren schmelzen mir gerade von der Wand, da sie die geforderte Temperatur des Nachbarraums erreichen möchten. ::)
Zitat von: FroggyFrog am 21 Januar 2017, 10:05:30
...Bei mir schien das Problem darin bestanden zu haben, dass das Thermostat vorher direkt mit der VCCU gepairt war. Ist aber nur eine Vermutung...
Zitat...Die Frage von Badflex stellt sich mir auch. Wie verhindere ich bei einer Fehlfunktion, dass der Heizkörper weiter heizt, obwohl die Solltemperatur schon erreicht, nur halt nicht korrekt übermittelt worden ist...
Wenn der keinen Wert bekommt bzw. die Übermittlung nicht richtig funktioniert, nutzt der Thermostat wieder seine interne Messung.
Da die traditionell eher einen höheren Wert misst, regelt das Dingen eh runter oder meint sogar, ein offenes Fenster zu erkennen.
Zitat...Ich habe zwei Channel in der VCCU angelegt. Einen für das Bad (1) und einen für das Wohnzimmer (2). Nun ist es bei mir aus unerfindlichen Gründen passiert, dass das Thermostat welches mit chanNo (2) gepairt worden ist, eigenständig den chanNo auf (1) gewechselt hat. Er hat zwar noch den richtigen VCCU-Channel-Namen, hat nun aber die Termperatur aus dem Bad (1).
Hat jemand dafür eine Erklärung?
Das glaube ich nicht so wirklich.
Einen ähnlichen Effekt habe ich auch schon mal beobachtet, aber da lag es wohl eher an meiner Ungeduld und den zeitlichen Verschiebungen in Messung und Übetragung.
P.S.: Um die Verbindung Temp-Sensor - Thermostat wieder zu trennen geht Du wie beim peeren vor, allerdings mit unset dahinter.
sinngemäß:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather unset
Hallo guten Tag
ich habe ein Problem nachdem ich mein Produktionssystem neu aufgesetzt habe (ja - never change a running system - selber Schuld...)
Ich habe gleichzeitig eine VCCU installiert. Zur Zeit betreibe ich nur einen HM-Sec-SC2 und 1 Thermostat am Heizkörper in der Küche.
Vorher hatte das mit einem virtuellen. Sensor funktioniert.
Nun habe ich das Problem dass ich keinen virtuellen. Sensor mit der gleich HMId anlegen kann.
Wenn ich wie im Wiki beschrieben define wz_vT CUL_HM <hmId> einen vt anlegen will bekomme ich die Meldung
dass diese HMId bereits von der VCCU verwendet wird.
Hier ein List der VCCU
Internals:
DEF 220355
HMUSB_MSGCNT 16
HMUSB_RAWMSG E3F567C,0000,002B1E03,FF,FFB7,C686703F567C00000000E01D
HMUSB_RSSI -73
HMUSB_TIME 2017-02-11 15:52:54
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 16
NAME VCCU
NOTIFYDEV global
NR 26
STATE HMUSB:ok,
TYPE CUL_HM
assignedIOs HMUSB
Readings:
2017-02-10 18:09:18 RegL_00.
2017-02-11 15:15:07 state HMUSB:ok,
2017-02-11 04:06:56 unknown_005DBF received
2017-02-11 15:52:54 unknown_3F567C received
2017-02-11 10:14:13 unknown_4100AB received
2017-02-10 18:21:47 unknown_4D242F received
Helper:
HM_CMDNR 134
mId FFF0
rxType 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
prefIO
vccu
ioList:
HMUSB
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
vrt 1
Tmpl:
Attributes:
IODev HMUSB
IOList HMUSB
expert 2_raw
model CCU-FHEM
room HM-Steuerung
subType virtual
webCmd virtual:update
und ein List meines iODev = HM-CFG-USB (HMUSB)
Internals:
DEF 127.0.0.1:1234
DeviceName 127.0.0.1:1234
FD 11
HMUSB_MSGCNT 31
HMUSB_TIME 2017-02-11 15:53:05
IFmodel USB
NAME HMUSB
NR 24
NTFY_ORDER 50-HMUSB
PARTIAL
RAWMSG E4100AB,0000,002B4B38,FF,FFC5,8586104100AB0000000AB1060D0000
RSSI -59
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 2
msgKeepAlive dlyMax:0.012 bufferMin:4
msgLoadCurrent 1
msgLoadHistoryAbs 5min steps: 1/1/1/1/1/1/1/1/1/0/0/0
msgParseDly min:3 max:76 last:46 cnt:29
owner 220355
owner_CCU VCCU
uptime 000 00:49:13.769
Readings:
2017-02-11 15:15:03 D-HMIdAssigned 220355
2017-02-11 15:15:03 D-HMIdOriginal 1ACE7F
2017-02-11 15:15:03 D-firmware 0.967
2017-02-11 15:15:03 D-serialNr JEQ0120882
2017-02-11 15:15:04 Xmit-Events init:1 disconnected:1 ok:1
2017-02-11 15:15:04 cond ok
2017-02-11 15:55:02 loadLvl low
2017-02-11 15:15:01 prot_disconnected last
2017-02-11 15:15:01 prot_init last
2017-02-11 15:15:04 prot_ok last
2017-02-11 15:15:01 state opened
Helper:
assIdCnt 2
assIdRep 2
info 03C7,JEQ0120882,1ACE7F,220355
setTime 45374
Cnd:
0 1
253 1
255 1
Dly:
cnt 29
lst 46
max 76
min 3
Ids:
4100ab:
cfg +4100AB,00,00,00
name HM_4100AB
4d242f:
cfg +4D242F,00,00,00
name Eingangstuere
K:
BufMin 4
DlyMax 0.012
Next 1486824927.2572
Start 1486824902.2572
Loadlvl:
bl 40
a:
99
90
40
0
H:
0 low
40 batchLevel
90 high
99 suspended
Log:
all 0
sys 0
ids:
ARRAY(0x21679d8)
Q:
HMcndN 0
answerPend 0
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 0
loadNo 11
scnt 1
ald:
1
1
1
1
1
1
1
1
1
0
0
0
apIDs:
Ref:
drft 7.99648154811883e-05
hmtL 2953769
kTs 0
offL 1486821948499
sysL 1486824877263
Attributes:
hmId 220355
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
room HM-Steuerung
Wo mache ich hier bitte den Fehler
Gruß
Helmut
Ich muss doch sie gleiche HMId verwenden oder?
Hello - konnte es lösen - hoffe richtig? Aber es funktioniert!
Falles es auch jemand anderer sucht - hier MEIN Ergebnis:
Virtuellen Sensor anlegen
define vt_Ku CUL_HM 22035501
Wird in der VCCU als Kanal 1 angelegt
Den virtuellen Sensor mit dem Weather Channel peeren
set vt_Kueche peerChan 0 HM_4100AB_Weather single
Peering kontrollieren
set hm peerXref
Gemessene Temperatur in den virt. HM Sensor übergeben
define at_vt_Ku at +*00:02 { my $T=(ReadingsVal("Kueche","temperature",20.0));; fhem "set vt_Kueche virtTemp $T" }
Gruß
Helmut
du hättest auch einfach in der VCCU die Menge der gewünschten Virtuellen Kanäle bei "Set - Virtual - " per Schieber einstellen können und auf set klicken können. Damit werden die Kanäle angelegt mit denen Du dann Peeren kannst.
Danke für den Hinweis - werde ich in MEINE Doku aufnehmen
Nice eve
Helmut
Ich habe das ganze mal probiert, solange man nur einen Sensor hat den man mit einem Thermsotat verbinden möchte klappt das ganz gut, ich habe aber 5 Sensoren mit 8 Thermostaten.
Ich habe nun Versucht dem virtuellen Device mehrere Channels anzulegen und dann das ganze via Job zu schreiben, gepeered sind erst mal nur 3 Thermostate mit zwei sensorgen.
#Virtueller Device für Temperatur an Thermostate
define Wohnzimmer_virt_Temperatur CUL_HM A4E21F
attr Wohnzimmer_virt_Temperatur IODev nanoCUL
attr Wohnzimmer_virt_Temperatur expert 2_raw
attr Wohnzimmer_virt_Temperatur group Virutelle-Sensoren-Heizungssteuerung
attr Wohnzimmer_virt_Temperatur model virtual_3
attr Wohnzimmer_virt_Temperatur msgRepeat 0
attr Wohnzimmer_virt_Temperatur room Temperatur_Virtual
attr Wohnzimmer_virt_Temperatur subType virtual
attr Wohnzimmer_virt_Temperatur webCmd virtual
# Sensor 1 für Thermostat Fenster
define Wohnzimmer_virt_Temperatur_Sensor1 CUL_HM A4E21F01
attr Wohnzimmer_virt_Temperatur_Sensor1 model virtual_1
attr Wohnzimmer_virt_Temperatur_Sensor1 peerIDs 51A3D901,
attr Wohnzimmer_virt_Temperatur_Sensor1 webCmd press short:press long
#Sensor 2 für Thermostat Türe
define Wohnzimmer_virt_Temperatur_Sensor2 CUL_HM A4E21F02
attr Wohnzimmer_virt_Temperatur_Sensor2 model virtual_2
attr Wohnzimmer_virt_Temperatur_Sensor2 peerIDs 51A3E501,
attr Wohnzimmer_virt_Temperatur_Sensor2 webCmd press short:press long
#Sensor 3 für Thermostat Schlafzimmer Fenster
define Schlafzimmer_virt_Temperatur_Sensor1 CUL_HM A4E21F03
attr Schlafzimmer_virt_Temperatur_Sensor1 model virtual_3
attr Schlafzimmer_virt_Temperatur_Sensor1 peerIDs 30A1A801,
attr Schlafzimmer_virt_Temperatur_Sensor1 webCmd press short:press long
#Jobs
define at_Wohnzimmer_virt_Temperatur1 at +*00:02 { my $T=(ReadingsVal("Wohnzimmer_Temperatur","temperature",20.0));; fhem "set Wohnzimmer_virt_Temperatur_Sensor1 virtTemp $T" }
define at_Wohnzimmer_virt_Temperatur2 at +*00:02 { my $T=(ReadingsVal("Wohnzimmer_Temperatur","temperature",20.0));; fhem "set Wohnzimmer_virt_Temperatur_Sensor2 virtTemp $T" }
define at_Schlafzimmer_virt_Temperatur1 at +*00:02 { my $T=(ReadingsVal("Schlafen_Temperatur","temperature",20.0));; fhem "set Schlafzimmer_virt_Temperatur_Sensor1 virtTemp $T" }
Laut log werden die werte auch ordentlich in die virtuellen Temperatursensoren geschrieben und die peerings passen
2017.04.16 23:41:47 3: CUL_HM set Schlafzimmer_virt_Temperatur_Sensor1 virtTemp 20.8
2017.04.16 23:41:47 3: CUL_HM set Schlafzimmer_virt_Temperatur_Sensor1 virtHum 0
....
peerXref done:
x-ref list
Schlafzimmer_Heizung_Fenster_Weather => Schlafzimmer_virt_Temperatur_Sensor1
Schlafzimmer_virt_Temperatur_Sensor1 => Schlafzimmer_Heizung_Fenster_Weather
Wohnzimmer_Heizung_Fenster_Weather => Wohnzimmer_virt_Temperatur_Sensor1
Wohnzimmer_Heizung_Tuere_Weather => Wohnzimmer_virt_Temperatur_Sensor2
Wohnzimmer_virt_Temperatur_Sensor1 => Wohnzimmer_Heizung_Fenster_Weather
Wohnzimmer_virt_Temperatur_Sensor2 => Wohnzimmer_Heizung_Tuere_Weather
Irgendwie spielen aber nun meine Thermostate verrückt, die IST Temperatur wird irgendwie nicht ordentlich übermittelt und auch nicht korrekt angezeigt.
Wo habe ich den Fehler? Bzw. hat jemand eine Idee?
Auch wenn ich nicht verstehe warum, es hat so funktioniert.
Erstelle zwei vCCUs, die erste bedient mit jeweils einem virt. Aktor zwei Thermostate, die zweite einen.
define virtualCCU_WZ CUL_HM 22ABCD
attr virtualCCU_WZ IODev nanoCUL
attr virtualCCU_WZ expert 2_raw
attr virtualCCU_WZ model CCU-FHEM
attr virtualCCU_WZ room Heizung
attr virtualCCU_WZ subType virtual
attr virtualCCU_WZ webCmd virtual:update
define virtualCCU_WZ_Sensor1 CUL_HM 22ABCD01
attr virtualCCU_WZ_Sensor1 model CCU-FHEM
attr virtualCCU_WZ_Sensor1 peerIDs 51A3D901,
attr virtualCCU_WZ_Sensor1 webCmd virtTemp
define virtualCCU_WZ_Sensor2 CUL_HM 22ABCD02
attr virtualCCU_WZ_Sensor2 model CCU-FHEM
attr virtualCCU_WZ_Sensor2 peerIDs 51A3E501,
attr virtualCCU_WZ_Sensor2 webCmd virtTemp
define virtualCCU_SZ CUL_HM 23ABCD
attr virtualCCU_SZ IODev nanoCUL
attr virtualCCU_SZ expert 2_raw
attr virtualCCU_SZ model CCU-FHEM
attr virtualCCU_SZ room Heizung
attr virtualCCU_SZ subType virtual
attr virtualCCU_SZ webCmd virtual:update
define virtualCCU_SZ_Sensor1 CUL_HM 23ABCD01
attr virtualCCU_SZ_Sensor1 model CCU-FHEM
attr virtualCCU_SZ_Sensor1 peerIDs 30A1A801,
attr virtualCCU_SZ_Sensor1 webCmd virtTemp
Passt das so?
Hallo,
ist es eigentlich auch möglich, dem Thermostat HM-TC-IT-WM-W-EU die Temperatur (aber ohne Luftfeuchtigkeit) zu übergeben?
Ich steuere damit nämlich die Fußbodenheizung und habe in den Räumen 1-wire Sensoren, welche an besseren Positionen verbaut sind, als das Thermostat.
Hallo,
ich habe gemäss dem Wiki den virtuellen Sensor eingerichtet und kriege immer diese Fehlermeldung:
set HM_Virt_Sensor1 virtTemp 22.5 : Unknown argument virtTemp, choose one of peerChan postEvent press.
Was mache ich falsch?
leo
Ich muss mich hier auch mal anschließen. Wollte das heute umsetzen, weil auf dem Klo immer viel zu hoch vom RT gemessen wird. Folgende Frage vorab: Was ist mit
Zitat_deiner_ HM Id
gemeint?
Hier ein List der Device:
Der RT Clima Kanal:
Internals:
CFGFN
CHANGED
DEF 2BCDB004
NAME WC.HZ_Clima
NOTIFYDEV global
NR 74
NTFY_ORDER 50-WC.HZ_Clima
STATE T: 21.5 desired: 19.5 valve: 0
TYPE CUL_HM
chanNo 04
device WC.HZ
Helper:
DBLOG:
ValvePosition:
Logdb_Heizung:
TIME 1512493579.13441
VALUE 0
desired-temp:
Logdb_Heizung:
TIME 1512492672.34392
VALUE 19.5
measured-temp:
Logdb_Heizung:
TIME 1512493761.79819
VALUE 21.5
state:
Logdb_Heizung:
TIME 1509728874.83974
VALUE T: 21.4 desired: 20.0 valve: 0
READINGS:
2017-12-04 22:00:45 CommandAccepted yes
2017-03-27 18:53:30 R-boostPeriod 5 min
2017-03-27 18:53:30 R-boostPos 80 %
2017-03-27 18:53:30 R-btnNoBckLight off
2017-03-27 18:53:30 R-dayTemp 21 C
2017-03-27 18:53:30 R-daylightSaveTime on
2017-03-27 18:53:30 R-decalcTime 11:00
2017-03-27 18:53:30 R-decalcWeekday Sat
2017-03-27 18:53:30 R-modePrioManu all
2017-03-27 18:53:30 R-modePrioParty all
2017-03-27 18:53:30 R-nightTemp 17 C
2017-03-27 18:53:30 R-noMinMax4Manu off
2017-03-27 18:53:30 R-regAdaptive on
2017-03-27 18:53:30 R-reguExtI 15
2017-03-27 18:53:30 R-reguExtP 30
2017-03-27 18:53:30 R-reguExtPstart 30
2017-12-03 20:58:35 R-reguIntI 12
2017-12-03 20:58:35 R-reguIntP 27
2017-12-04 14:40:37 R-reguIntPstart 14
2017-03-27 18:53:30 R-showInfo time
2017-03-27 18:53:30 R-showWeekday off
2017-03-27 18:53:26 R-sign off
2017-03-27 18:53:30 R-tempMax 30.5 C
2017-03-27 18:53:30 R-tempMin 4.5 C
2017-03-27 18:53:30 R-tempOffset 0.0K
2017-03-27 18:53:30 R-valveErrPos 15 %
2017-03-27 18:53:30 R-valveMaxPos 100 %
2017-03-27 18:53:30 R-valveOffsetRt 0 %
2017-03-27 18:53:30 R-winOpnBoost off
2017-04-02 10:22:01 R-winOpnDetFall 1.4 K
2017-04-02 10:22:01 R-winOpnMode off
2017-03-27 18:53:30 R-winOpnPeriod 15 min
2017-03-27 18:53:30 R-winOpnTemp 12 C
2017-12-05 18:09:32 R_0_tempListSat 06:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_1_tempListSun 06:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_2_tempListMon 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_3_tempListTue 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_4_tempListWed 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_5_tempListThu 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_6_tempListFri 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
2017-12-05 18:09:32 R_tempList_State verified
2017-12-05 18:09:27 RegL_01. 08:00 00:00
2017-12-05 18:09:32 RegL_07. 01:2A 02:22 03:09 04:3D 05:18 06:03 07:00 08:16 09:07 0A:30 0B:00 0C:64 0D:0F 0E:05 0F:00 10:00 11:00 12:09 13:0E 14:44 15:48 16:55 17:08 18:45 19:20 1A:45 1B:20 1C:45 1D:20 1E:45 1F:20 20:45 21:20 22:45 23:20 24:45 25:20 26:45 27:20 28:45 29:20 2A:45 2B:20 2C:45 2D:20 2E:44 2F:48 30:55 31:08 32:45 33:20 34:45 35:20 36:45 37:20 38:45 39:20 3A:45 3B:20 3C:45 3D:20 3E:45 3F:20 40:45 41:20 42:45 43:20 44:45 45:20 46:45 47:20 48:44 49:48 4A:54 4B:6C 4C:44 4D:CC 4E:55 4F:08 50:45 51:20 52:45 53:20 54:45 55:20 56:45 57:20 58:45 59:20 5A:45 5B:20 5C:45 5D:20 5E:45 5F:20 60:45 61:20 62:44 63:48 64:54 65:6C 66:44 67:CC 68:55 69:08 6A:45 6B:20 6C:45 6D:20 6E:45 6F:20 70:45 71:20 72:45 73:20 74:45 75:20 76:45 77:20 78:45 79:20 7A:45 7B:20 7C:44 7D:48 7E:54 7F:6C 80:44 81:CC 82:55 83:08 84:45 85:20 86:45 87:20 88:45 89:20 8A:45 8B:20 8C:45 8D:20 8E:45 8F:20 90:45 91:20 92:45 93:20 94:45 95:20 96:44 97:48 98:54 99:6C 9A:44 9B:CC 9C:55 9D:08 9E:45 9F:20 A0:45 A1:20 A2:45 A3:20 A4:45 A5:20 A6:45 A7:20 A8:45 A9:20 AA:45 AB:20 AC:45 AD:20 AE:45 AF:20 B0:44 B1:48 B2:54 B3:6C B4:44 B5:CC B6:55 B7:08 B8:45 B9:20 BA:45 BB:20 BC:45 BD:20 BE:45 BF:20 C0:45 C1:20 C2:45 C3:20 C4:45 C5:20 C6:45 C7:20 C8:45 C9:20 CA:0C CB:1B CC:0E CD:0F CE:1E CF:1E 00:00
2017-12-05 18:19:54 ValvePosition 0
2017-12-05 18:19:54 boostTime -
2017-12-05 18:19:54 controlMode manual
2017-12-05 18:19:54 desired-temp 19.5
2017-12-05 18:19:54 measured-temp 21.5
2017-12-05 18:19:54 partyEnd -
2017-12-05 18:19:54 partyStart -
2017-12-05 18:19:54 partyTemp -
2017-12-04 22:00:45 recentStateType ack
2017-12-05 18:19:54 state T: 21.5 desired: 19.5 valve: 0
helper:
peerIDsRaw ,00000000
expert:
def 1
det 1
raw 1
tpl 1
role:
chn 1
shRegR:
07 00
shadowReg:
tmpl:
Attributes:
alexaName WC Heizung
alexaRoom WC
alias Heizung WC
event-min-interval measured-temp:1800,desired-temp:1800,ValvePosition:1800
event-on-change-reading state,desired-temp,measured-temp,ValvePosition,controlMode
expert 251_anything
genericDeviceType thermostat
group Heizung
model HM-CC-RT-DN
peerIDs 00000000,
room Räume--WC,Z_System--Homematic,Z_Räume--WC,Z_System--alexa
structexclude WG.HZ.Alle:.*
userattr structexclude wohnung wohnung_map
wohnung WG.HZ.Alle
wohnung_map desired-temp Der RT Weather Kanal:
Internals:
CFGFN
DEF 2BCDB001
NAME WC.HZ_Weather
NOTIFYDEV global
NR 71
NTFY_ORDER 50-WC.HZ_Weather
STATE 21.5
TYPE CUL_HM
chanNo 01
device WC.HZ
peerList WC.vT_Sensor,
READINGS:
2017-03-27 18:53:23 R-sign off
2017-12-05 18:09:25 RegL_01. 08:00 00:00
2017-12-05 18:19:54 measured-temp 21.5
2017-12-05 18:09:24 peerList WC.vT_Sensor,
2017-12-05 18:19:54 state 21.5
helper:
peerIDsRaw ,12345701,00000000
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
group CUL_HM
model HM-CC-RT-DN
peerIDs 00000000,12345701,
room Z_System--Homematic Ein List des At:
Internals:
CFGFN
COMMAND { my $T=(ReadingsVal("WC.Fuehler","temperature",20.0)); fhem "set WC.vT_Sensor virtTemp $T" }
DEF +*00:02 { my $T=(ReadingsVal("WC.Fuehler","temperature",20.0)); fhem "set WC.vT_Sensor virtTemp $T" }
NAME AT.HZ.WC.Virtuel
NR 386727
NTM 18:24:59
PERIODIC yes
RELATIVE yes
REP -1
STATE Next: 18:24:59
TIMESPEC 00:02
TRIGGERTIME 1512494699.53396
TRIGGERTIME_FMT 2017-12-05 18:24:59
TYPE at
READINGS:
2017-12-05 18:22:59 state Next: 18:24:59
Attributes:
room Z_System--DOIF Im Log sehe ich folgende Meldung:
2017.12.05 18:11:30 3: CUL_HM set WC.vT_Sensor virtTemp 18
2017.12.05 18:12:59 3: CUL_HM set WC.vT_Sensor virtTemp 18
2017.12.05 18:14:59 3: CUL_HM set WC.vT_Sensor virtTemp 18
2017.12.05 18:16:59 3: CUL_HM set WC.vT_Sensor virtTemp 18.1
2017.12.05 18:18:59 3: CUL_HM set WC.vT_Sensor virtTemp 18.1
2017.12.05 18:20:59 3: CUL_HM set WC.vT_Sensor virtTemp 18.1
2017.12.05 18:22:59 3: CUL_HM set WC.vT_Sensor virtTemp 18.1Aber weder im Clima noch im Weather Kanal sehe ich den Wert vom Sensor stehen, sondern immer noch den viel zu Hohen Wert des RT.
Edit:
ConfigCheck:
configCheck done:
PairedTo missing/unknown
WC.vT
PeerXRef:
WC.HZ_Weather => WC.vT_Sensor
WC.HZ_WindowRec => WC.Fenster
WC.vT_Sensor => WC.HZ_Weather
Scheinbar funktioniert es jetzt, warum auch immer. Woran erkenne ich, dass der Wert nicht angenommen wurde und es zu den hier beschriebenen Fehlern kommt? Wenn die measured-temp im Plot auf einmal gesprungen ist zum Beispiel?
ja... er nimmt dann plötzlich wieder die am Thermostat intern gemessene Temperatur und dadurch kommt es zu einem leichten Sprung in der Kurve.
Ich hatte früher einen Heizkörper wo ich solche Ausfälle alle 2 Minuten hatte. Meine Lösung war das Attribut "cyclicMsgOffset" beim Thermostat (Kanal 4) auf 300 zu setzen. Damit klappt es sehr gut.
Grüße
Stephan
@Amenophobis
Könntest Du bitte auch die config des virtuellen Sensors posten? Ich krieg die Fehlermeldung nicht weg. Die virt tem wird einfach nciht akzeptiert.
Schreibe es mir auf die Liste fürs Wochenende und versuche dran zu denken
Zitat von: nuart am 07 Dezember 2017, 18:14:33
@Amenophobis
Könntest Du bitte auch die config des virtuellen Sensors posten? Ich krieg die Fehlermeldung nicht weg. Die virt tem wird einfach nciht akzeptiert.
Der Kanal
Internals:
CFGFN
DEF 12345701
NAME WC.vT_Sensor
NOTIFYDEV global
NR 387010
STATE set_virtTemp 18.6
TYPE CUL_HM
chanNo 01
device WC.vT
peerList WC.HZ_Weather,
READINGS:
2017-12-05 18:08:44 peerList WC.HZ_Weather,
2017-12-08 16:00:59 state set_virtTemp 18.6
2017-12-08 16:00:59 temperature 18.6
helper:
fkt virtThSens
virtTC 00
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
tmpl:
vd:
ackT
cmd 8470123457000000
idh 1044004
idl 22272
miss 0
msgCnt 118
msgRed 0
next 1512745392.62457
nextM 1512745392.62457
typ 2
val 00BA
vin 18.6
Attributes:
model virtual_1
peerIDs 2BCDB001,
verbose 2
webCmd press short:press long Das Device
Internals:
CFGFN
DEF 123457
IODev HMLAN1
NAME WC.vT
NOTIFYDEV global
NR 387008
STATE CMDs_done
TYPE CUL_HM
channel_01 WC.vT_Sensor
protSnd 1654 last_at:2017-12-08 16:00:59
protState CMDs_done
READINGS:
2017-12-08 16:00:59 state CMDs_done
helper:
HM_CMDNR 47
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +123457,00,00,00
prefIO
rxt 0
vccu
p:
123457
00
00
00
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
tmpl:
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
expert 2_raw
model virtual_1
msgRepeat 0
subType virtual
Danke. Ich werd meine config nochmal checken.
Ich bekomme bei dem Befehl
Zitat von: jab am 03 Februar 2014, 01:52:01
set virtual_temp virtual 1
den Fehler
Unknown argument virtual choose one of peerChan postEvent pressWas kann das Problem sein?
Was soll das denn für ein Befehl sein?
Zitat von: Amenophis86 am 27 Februar 2018, 11:53:06
Was soll das denn für ein Befehl sein?
Zitat von: tpm88 am 21 Dezember 2014, 22:50:56
das funktioniert bei mir einwandfrei. Hier nochmal Schritt für Schritt:
1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>
2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1
Joa, dann mal ein List von virtual_temp
Zitat von: Amenophis86 am 27 Februar 2018, 12:35:22
Joa, dann mal ein List von virtual_temp
Internals:
CFGFN
DEF 22334402
NAME DG.Sz.vT.Temperatur
NOTIFYDEV global
NR 17110
STATE ???
TYPE CUL_HM
chanNo 02
device DG.Kz.vT.Temperatur
READINGS:
helper:
expert:
def 1
det 0
raw 0
tpl 0
role:
chn 1
vrt 1
tmpl:
Attributes:
DbLogExclude .*
model virtual_1
webCmd press short:press long
Mmmmh wundert mich gerade auch. Hast du es mal gelöscht und neu angelegt?
Zitat von: Amenophis86 am 27 Februar 2018, 19:39:36
Mmmmh wundert mich gerade auch. Hast du es mal gelöscht und neu angelegt?
Ja, wegen dem genannten Fehler!
deine infos sind ziehmlich verwirrend.
du postest list's von devices die nichts mit den "nicht funktionierenden befehlen" zu tun haben. völlig andere namen.
im letzten list ist die kanalnummer seltsam. chn2 an einem device mit einem channel.
lösch mal die attr expert in den virtuellen entities.
ach so, ... set virtual ist nur im hauptdevice gültig. scheinbar hast du es im channel probiert, wegen den fehlermeldumgen.
ausserdem immer nur virt devices mit einem chn nutzen.
Die Namen waren nur Beispiele.
Es existiert kein Attribut ,,expert"
Ah gut gesehen Frank. Hab gar nicht mehr auf den Namen geachtet, aber klar,da liegt der Fehler :)
Ich hoffe ich habe es jetzt verstanden:
Bisher hatte ich ja nur einen HM-CC-RT-DN der mit einem Lacrosse Sensor verbunden war.
Da ich jetzt einen zweiten HM-CC-RT-DN mit einem anderen Lacrosse Sensor verbinden will benötige ich kein neues virtuelles HomeMatic Device?
Ich muss dem vorhandenen virtuellen HomeMatic Device nur einen neuen Kanal zuordnen?
Ist das so korrekt?
Kann ich das vorhandene virtuelle HomeMatic Device mit rename gefahrlos umbenennen?
Zitat von: Fredi69 am 28 Februar 2018, 09:04:33
Ich muss dem vorhandenen virtuellen HomeMatic Device nur einen neuen Kanal zuordnen?
Ist das so korrekt?
Es gab da neulich eine Diskussion zu, und da war das Ergebnis nach meiner Erinnerung: Besser für jeden virtuellen Temp-Sensor ein eigenes Device anlegen, aus irgendeinem unerfindlichen Grund scheint sich der RT sonst nur die Werte aus dem ersten Kanal zu greifen (also nur der eine Temp-Sensor wird an alle RT's weitergegeben...).
Zitat von: Fredi69 am 28 Februar 2018, 09:04:33
...
Da ich jetzt einen zweiten HM-CC-RT-DN mit einem anderen Lacrosse Sensor verbinden will benötige ich kein neues virtuelles HomeMatic Device?
Ich muss dem vorhandenen virtuellen HomeMatic Device nur einen neuen Kanal zuordnen?...
NEIN.
Genau das funktioniert nicht.
Tu Dir selbst einen Gefallen und erstell Dir zu jedem Sensor ein passendes virtuelles Device.
Dann kannst Du das namentlich vernünftig zuordnen und es funktioniert auch dauerhaft.
Ich habe jetzt das virtuelle Device mit dem Weather Channel gepeert.
set DG.Sz.vT.Temperatur_Sensor1 peerChan 0 DG.Sz.HZ.Thermostat_Weather single
Im Virtuellen Device kann ich die Verbindung zum Weather Channel sehen, im Weather Channel sind die peerIDs leider leer bzw. 00000000.
Was mache ich falsch?
An das Ende Deines Kommandos gehört eigentlich noch ein set oder unset, je nach Wunsch.
set DG.Sz.vT.Temperatur_Sensor1 peerChan 0 DG.Sz.HZ.Thermostat_Weather single set
Du hast danach aber schon gewartet bis die pending commands auf done wechseln und dann mal aktualisiert!?
Zitat von: Hollo am 01 März 2018, 21:10:47
An das Ende Deines Kommandos gehört eigentlich noch ein set oder unset, je nach Wunsch.
set DG.Sz.vT.Temperatur_Sensor1 peerChan 0 DG.Sz.HZ.Thermostat_Weather single set
Du hast danach aber schon gewartet bis die pending commands auf done wechseln und dann mal aktualisiert!?
Das
set fehlt leider auch im Wiki.
Aber auch mit Set kommt im das Peering im Weather Channel nicht an, im virtuellen Device ist ein Peering angekommen.
Was mache ich da falsch, mit dem anderen Thermostat hat es ja schon mal geklappt.
Hiweis auf die Doku
ZitatpeerChan <btn_no> <actChan> [single|dual|reverse] [set|unset] [both|actor|remote]
Die Unterstreichungen sind default und können auch weggelassen werden.
Ich bin gerade total am durchdrehen, bis gestern abend hat das ganze bei mir einwandfrei funktioniert, aber jetzt werden die Werte aus dem virtuellen Sensor nicht mehr in den Weather Kanal geschrieben. Also habe ich mein Thermostat und den virtuellen Sensor komplett gelöscht und zurückgesetzt. Und dann nochmal nach der Anleitung fortgefahren, jedoch mit dem gleichen Problem.
Ich scheine das gleiche Problem wie @Fredi69 zu haben.
Es kommt bei der überprüfung mit "set hm peerXref" nur:
peerXref done:
x-ref list
wz_vT_Sensor1 => sz_heizung_Weather
wiederholen bis es passt.
löschen und resetten von devices bringt nur zusätzliche probleme, wie du nun selbst siehst. also völlig überflüssig.
verfolge die kommunikation im thermostat. erst cmds_done zeigt erfolg. mache vorher ein set clear msgEvents, damit nicht noch weitere befehle in der cmd-queue existieren.
zum sofortigen ausführen des peering befehls am besten den "countdown" am thermostat starten. eventuell mehrmals, falls noch cmds pending gezeigt werden.
Also das Thermostat ist richtig gepeered. Es wird auch cmds_done angezeigt. Das Problem ist ja das peering mit meinem virtuellen Sensor. Oder meinst du dass ich den befehl zum peeren des virtuellen Sensors mit dem Thermostat so oft durch führen soll bis es klappt?
ZitatOder meinst du dass ich den befehl zum peeren des virtuellen Sensors mit dem Thermostat so oft durch führen soll bis es klappt?
ja. was sonst?
Also ich hatte jetzt als ausgangszustand ja, dass das Thermostat in fhem gelöscht ist und auf werkseinstellungen zurückgesetzt ist.
1. Peeren des Thermostates mit fhem
- warten bis CMDs_done erscheint
2. virtuelles hm device erstellt
define wz_vT CUL_HM 112233
und weiter nach der Anleitung verfahren bis zu dem Punkt, an dem der virtuelle Sensor mit dem Thermostat gepperd wird. Diesen Punkt habe ich bestimmt 10-mal durchgeführt und es kam mit peerXref immer die gleiche Ausgabe:"wz_vT_Sensor1 => sz_heizung_Weather"
auch ein neustart von fhem mit shutdown restart konnte mir nicht helfen, das einzige was sich dadurch änderte wer der status von meinem Virtuellen sensor, dieser änderte sich von "? ? ?" auf "stopped"
Wie soll ich nun weiter verfahren?
poste mal je ein list, insgesamt also 4:
themostat hauptdevice
thermostat weatherchannel
virt sensor hauptdevice
virt sensor channel
Liest Thermostat Hauptdevice:
Internals:
DEF 5F94D8
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 5
NAME sz_heizung
NOTIFYDEV global
NR 270
NTFY_ORDER 50-sz_heizung
STATE CMDs_done
TYPE CUL_HM
channel_01 sz_heizung_Weather
channel_02 sz_heizung_Climate
channel_03 sz_heizung_WindowRec
channel_04 sz_heizung_Clima
channel_05 sz_heizung_ClimaTeam
channel_06 sz_heizung_remote
lastMsg No:21 - t:10 s:5F94D8 d:526461 0208000000
myHmUART_MSGCNT 5
myHmUART_RAWMSG 0501001E2180105F94D85264610208000000
myHmUART_RSSI -30
myHmUART_TIME 2018-03-28 13:45:10
protLastRcv 2018-03-28 13:45:10
protResnd 1 last_at:2018-03-28 13:42:31
protSnd 4 last_at:2018-03-28 13:45:10
protState CMDs_done
rssi_at_myHmUART avg:-30.4 max:-30 cnt:5 lst:-30 min:-32
READINGS:
2018-03-28 13:41:18 Activity alive
2018-03-28 13:45:09 CommandAccepted yes
2018-03-28 13:37:16 D-firmware 1.4
2018-03-28 13:37:16 D-serialNr OEQ1697911
2018-03-28 12:57:37 PairedTo 0x526461
2018-03-28 12:57:37 R-backOnTime 10 s
2018-03-28 12:57:37 R-burstRx on
2018-03-28 12:57:37 R-cyclicInfoMsg on
2018-03-28 12:57:37 R-cyclicInfoMsgDis 0
2018-03-28 12:57:37 R-pairCentral 0x526461
2018-03-28 12:57:37 RegL_00. 01:01 02:01 09:01 0A:52 0B:64 0C:61 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00 00:00
2018-03-28 12:58:32 RegL_07.
2018-03-28 13:45:09 actuator 0
2018-03-28 13:45:09 battery ok
2018-03-28 13:45:09 batteryLevel 2.9
2018-03-28 13:45:09 desired-temp 20.0
2018-03-28 13:45:09 measured-temp 29.8
2018-03-28 13:45:09 motorErr ok
2018-03-28 13:45:10 state CMDs_done
2018-03-28 12:53:50 time-request -
helper:
HM_CMDNR 33
cSnd 015264615F94D80103,015264615F94D801040000000001
mId 0095
regLst ,0
rxType 140
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5F94D8,00,00,00
nextSend 1522237510.50609
prefIO
rxt 2
vccu
p:
5F94D8
00
00
00
mRssi:
mNo 21
io:
myHmUART:
-22
-22
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
prs 1
rssi:
at_myHmUART:
avg -30.4
cnt 5
lst -30
max -30
min -32
shRegW:
07 04
tmpl:
Attributes:
IODev myHmUART
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-CC-RT-DN
room CUL_HM
serialNr *********
subType thermostat
webCmd getConfig:clear msgEvents:burstXmit
List Thermostat Weatherchannel
Internals:
DEF 5F94D801
NAME sz_heizung_Weather
NOTIFYDEV global
NR 272
NTFY_ORDER 50-sz_heizung_Weather
STATE 29.9
TYPE CUL_HM
chanNo 01
device sz_heizung
READINGS:
2018-03-28 12:57:38 R-sign off
2018-03-28 13:45:10 RegL_01. 08:00 00:00
2018-03-28 13:47:36 measured-temp 29.9
2018-03-28 13:47:36 state 29.9
helper:
peerIDsRaw ,00000000
regLst ,1
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-CC-RT-DN
peerIDs 00000000,
List virt sensor Hauptdevice:
Internals:
DEF 11223301
NAME wz_vT_Sensor1
NOTIFYDEV global
NR 280
NTFY_ORDER 50-wz_vT_Sensor1
STATE stopped
TYPE CUL_HM
chanNo 01
device wz_vT
peerList sz_heizung_Weather,
READINGS:
2018-03-28 13:41:18 peerList sz_heizung_Weather,
2018-03-28 13:41:21 state stopped
helper:
fkt virtThSens
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
vrt 1
vd:
idh 0
idl 0
msgCnt 1
msgRed 0
next 1522237448.43982
nextM 1522237451.40458
Attributes:
model virtual_1
peerIDs 5F94D801,
webCmd press short:press long
List virt sensor channel:
Internals:
DEF 112233
NAME wz_vT
NOTIFYDEV global
NR 279
NTFY_ORDER 50-wz_vT
STATE ???
TYPE CUL_HM
channel_01 wz_vT_Sensor1
READINGS:
helper:
HM_CMDNR 219
mId
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
Attributes:
expert 2_raw
model virtual_1
subType virtual
webCmd virtual
Bei den letzten beiden lists bin ich mir nicht ganz sicher ob es das ist was du wolltest.
es sind die richtigen list's.
bei wz_vT fehlt das "attr IODev myHmUART" und "attr expert" löschen.
die rssi werte vom thermostat sind eventuell zu gut. versuch mal 2-3 m zwischen hmuart und thermostat.
wie sieht dein befehl zum peeren genau aus?
was sagt fhem log, wenn du peerst?
Zitat von: frank am 28 März 2018, 14:15:31
es sind die richtigen list's.
bei wz_vT fehlt das "attr IODev myHmUART" ....
Es besteht anscheinend immer noch das Problem, dass bei den virtuellen Devices das IODev nicht korrekt gesetzt wird.
Schau mal hier: https://forum.fhem.de/index.php/topic,85166.0.html (https://forum.fhem.de/index.php/topic,85166.0.html)
Ich habe jetzt zunächst einfach mal bei wz_vT das IODev gesetzt und das attribut expert gelöscht.
Mein hmuart ist tatsächlich nur 1m vom Thermostat entfernt, jedoch hat sich an der Entfernung nichts geändert. Früher hat es so ja auch funktioniert, aber gut, ich rücke es mal zur seite.
Mein Befehl zum peeren schaut so aus:
set wz_vT_Sensor1 peerChan 0 sz_heizung_Weather single
mein Logifle:
2018.03.28 19:23:48 3: myHmUART: Unknown code A0C5586702BBF7F00000000675F::-95:myHmUART, help me!
2018.03.28 19:25:53 3: myHmUART: Unknown code A0C5686702BBF7F00000000675F::-94:myHmUART, help me!
2018.03.28 19:28:47 3: myHmUART: Unknown code A0C5786702BBF7F00000000675F::-95:myHmUART, help me!
2018.03.28 19:31:27 3: myHmUART: Unknown code A0C5886702BBF7F00000000665F::-95:myHmUART, help me!
2018.03.28 19:33:53 3: myHmUART: Unknown code A0C5986702BBF7F00000000665F::-93:myHmUART, help me!
2018.03.28 19:35:10 1: No Logdevice FileLog_HMS100TF_0000
2018.03.28 19:35:10 1: No Logdevice FileLog_CUL_FHTTK_31178f
2018.03.28 19:35:14 3: CUL_HM set wz_vT_Sensor1 peerChan 0 sz_heizung_Weather single
2018.03.28 19:35:15 1: No Logdevice FileLog_CUL_FHTTK_31178f
2018.03.28 19:35:15 1: No Logdevice FileLog_HMS100TF_0000
Jezt hat das Peering funktioniert:
x-ref list
sz_heizung_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => sz_heizung_Weather
Und jetzt geht es endlich :)
wenn du die kommunikation mit dem thermostat nicht manuell startest (countdown), dauert es natürlich bis das thermostat von selber aufwacht.
dann mach jetzt save config, damit es weiterhin funktioniert.
noch eins: mit einer vccu verschwinden auch die "help me" einträge in fhem.log.
Hi,
ich muss hier nochmal ganz doof fragen.
Hab mir dummerweise zum Thermostat ein CCU2 gekauft 8)
Ich würde gerne fhem und die Thermostate mit externer Raumtemperatur via MQTT steuern/regeln lassen.
Dafür benötige ich anstelle einer CCU2 ein HMLAN also HM-LGW-O-TW-W-EU-2 ?????
Sorry bin neu bei fhem
LG
Zitat von: trollmars am 28 April 2018, 15:53:10
Hi,
ich muss hier nochmal ganz doof fragen.
Hab mir dummerweise zum Thermostat ein CCU2 gekauft 8)
Ich würde gerne fhem und die Thermostate mit externer Raumtemperatur via MQTT steuern/regeln lassen.
Dafür benötige ich anstelle einer CCU2 ein HMLAN also HM-LGW-O-TW-W-EU-2 ?????
Sorry bin neu bei fhem
LG
Kann hier keiner was dazu sagen?
Oder brauch ich einen CUL Stick?
Danke!!
Würde mal ein neues Thema im Homematic Forum auf machen, vielleicht bekommste dann ne Antwort.