Homematic mit Nicht Homematic verbinden.

[tpm88]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

wz_ds_temp { fhem "set wz_vT_Sensor1 virtTemp $EVTPART1" }

Zugehöriges Filelog des DS1820 Sensors:

Code Auswählen Erweitern

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

[blackdevil2k1]

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 ?

[Thorsten Pferdekaemper]

Hi,
hier ist die Definition einer meiner RTs:

Code Auswählen Erweitern


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

[DosiRocker]

Code Auswählen Erweitern

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

[roedert]

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?

[blackdevil2k1]

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

[jab]

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

[roedert]

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.

[jab]

Hi,

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?

Code Auswählen Erweitern


attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys


Gruß,
Jan

[blackdevil2k1]

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?

[Thorsten Pferdekaemper]

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

[blackdevil2k1]

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?

[roedert]

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?

[jab]

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

[tpm88]

Hallo,

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.

... 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?

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