Moin zusammen,
ich habe im Wohnzimmer zwei Funkstellantriebe. Nun ist der eine etwas blöd eingebaut, so dass die Temperatur dort nicht sehr repräsentativ ist, weil der HK in einer Niesche sitzt. Der zweite nimmt die Temperatur deutlich besser ab. Nun war mein Gedankengang, dass ich doch eigentlich den einen Weather Channel auf den zweiten setzen könnte?
ZitatChannel (Kanal) 01 _Weather
Dieser Kanal dient zur Einspeisung der gemessenen ("Ist"-) Temperatur, als Sensor kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.
Der Befehl zum peeren lautet, wobei <tempSensor> die Fhem-Kanalbezeichnung für den Sensor ist und <rt_Weather> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <tempSensor> peerChan 0 <rt_Weather> single
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_01_Weather
set CUL_HM_HM_CC_RT_DN_255464_Weather peerChan 0 CUL_HM_HM_CC_RT_DN_2551EA_Weather singleDann bekomme ich jedoch einen Fehler
Unknown argument peerChan, choose one of burstXmit clear:readings,trigger,register,rssi,msgEvents,all getConfig getRegRaw inhibit:on,off peerBulk regBulk regSet sign:on,off Irgendetwas mache ich falsch. Hat jemand eine Idee? Oder geht das gar nicht?
Interessante Frage, auf die ich keine Antwort weiß. Dennoch:
Der Kanal _Weather dient zwar als peer-Eingang, kann aber offenbar nicht selbst als Datenquelle dienen. Da bei HM in FHEM normalerweise konsequent vom Sender zum Empfänger gepeert wird, bietet "set" das peerChan im Dropdown folgerichtig nicht an. Das erklärt den geworfenen Fehler beim peering.
Aus http://forum.fhem.de/index.php/topic,27980.0.html (http://forum.fhem.de/index.php/topic,27980.0.html) weiß ich, dass die Übertragung von Temperaturen an den RT-DN wohl auch eine zeitkritische Sache ist - der RT-DN errechnet, wann ein Sensor funkt, und stellt seine Wachphasen darauf ab. Aufwecken mit Burst gibt es nur bei außerordentlichen Ereignissen wie einem Fensteröffnen (dann sendet der Fenstersensor einen Burst).
Aber ich bin RT-DN-Anfänger, vielleicht hat jemand eine bessere Idee, evtl. mit Umweg. Im Thread wird ja unter anderem erwähnt, dass jemand einen HM-Dummy mit 1-wire-Temperatursensor-Werten gefüttert hat, die an den RT-DN weitergegeben wurden. Offenbar gab es auch hier Sync-Probleme. Den HM-Dummy könnte man wiederum vom besser messenden Thermostaten befüttern lassen, etwa per Notify. Das ist aber eine Notlösung - eigentlich wäre eine direkte Kopplung und eine Unabhängigkeit von FHEM wünschenswert, wie oft eigentlich bei HM.
evtl. hilft dir ein vir. HM device welches dem Thermostat die richtige Temp sendet
http://www.fhemwiki.de/wiki/HomeMatic#Virtuelle_Entities
http://forum.fhem.de/index.php/topic,19686.0.html
devices, die unregelmäßig so alle 2min daten bekommen errechnen das nächste aufwachen anhand der aktuell empfangenen message.
Wir haben einen virtuellen wettersensor gebaut. diesen kannst du mit dem wetterkanal peeren. dann setzt du die temperatur im virtuellen Sensor und beim nächsten Senden wird deine temp an die peers des virt-temp sensors geschickt.
das, was du suchst?
dem virt-temp-sensor musst du aus einer dir genehmen quelle füttern.
Hi Martin,
ich denke, dass ist so ziemlich was ich möchte. Ich möchte die Temperatur der einen Stellantriebes als Weather Temp auf dem anderen nutzen. Wenn das über den Umweg geht mit einem virtuellen Sensor, dann super!
Kann ich das irgendwo im Forum finden?
definiere eine virtuellen Sensor
define vs CUL_HM 333333
set vs virtual 1
rename vs_Btn1 vsTemp
set vsTemp peerChan 0 rt_Weather single
set vsTemp virtTemp 20
probiere einmal. Die Namen kannst du sicher selbst ersetzen.
Das peeren am RT muss abgeschlossen sein, klar.
Evtl. brauchen vsTemp und rt etwas um sich zu finden.
Tests dauern etwas, da die temp nur alle ~2,5min gesendet wird - schneller geht nicht.
hmmmm. Irgendwie komme ich da nicht ganz weiter.....
Ich habe nun soweit den virtuellen Channel definiert
define virtual_temp_wz CUL_HM 123456
attr virtual_temp_wz IODev HMLAN1
attr virtual_temp_wz model virtual_1
attr virtual_temp_wz msgRepeat 0
attr virtual_temp_wz subType virtual
attr virtual_temp_wz webCmd virtual
define virtual_temp_wz_Sensor1 CUL_HM 12345601
attr virtual_temp_wz_Sensor1 model virtual_1
attr virtual_temp_wz_Sensor1 peerIDs [b]2551EA01[/b],
attr virtual_temp_wz_Sensor1 webCmd virtTemp:virtHum
Der wird mir auch schön angezeigt. Ich habe diesen mal testhalber direkt im FHem mit Daten befüllt auf 16.0 °C, was auch ging. Leider kann ich jedoch an meinem RT Weather Channel keine Veränderung feststellen. Der ist nun wie folgt definiert:
define CUL_HM_HM_CC_RT_DN_2551EA_Weather CUL_HM 2551EA01
attr CUL_HM_HM_CC_RT_DN_2551EA_Weather alias HK.Wohnzimmer.2.Weather
attr CUL_HM_HM_CC_RT_DN_2551EA_Weather event-on-change-reading no
attr CUL_HM_HM_CC_RT_DN_2551EA_Weather expert 1
attr CUL_HM_HM_CC_RT_DN_2551EA_Weather model HM-CC-RT-DN
attr CUL_HM_HM_CC_RT_DN_2551EA_Weather peerIDs [b]12345601[/b],
Mit dem folgenden notify wollte ich den auch dann befüllen. Stehe irgendwie auf dem Schlauch:
define HK.Wohnzimmer.virt.Temp notify CUL_HM_HM_CC_RT_DN_2551EA_Weather:measured-temp.* {\
if ($EVTPART1 ne ReadingsVal("CUL_HM_HM_CC_RT_DN_255464_Weather","measured-temp","")){\
fhem "set virtual_temp_wz_Sensor1 virtTemp $EVTPART1"}\
}
attr HK.Wohnzimmer.virt.Temp room notify
Müsste ich nicht im Weather Channel des HK.Wohnzimmer.2.Weather dann die gemessene Temperatur des virtuellen sehen?
Sendet der virtuelle revelmaessig ?
Kann ich nicht genau sagen. Ichmeine aber nicht. Kann weder imLog noch im EventMonwas sehen.Denke also eher nicht.
Zitatif ($EVTPART1 ne ReadingsVal("CUL_HM_HM_CC_RT_DN_255464_Weather","measured-temp","")){\
vergleich von nummern auf ungleich => "!="