Peering HM-TC-IT-WM-W-EU mit HM-CC-VD zerschießt fhem.cfg

[martinp876]

peeren ist separat auf jeder seite. dass der TC1 dies anzeigt ist also ok, hat nichts mit der Sicht den VD zu tun.

im VD hängt noch eine message. da er nicht gepeert ist musst du config drücken, damit er diese Verarbeitet.

[dan1180]

Config drücken? Meinst du die Anlerntaste? Wenn ja, leider keine Reaktion. Inzwischen habe ich auch ein "MISSING ACK in meinem Virtuellen Schalter. Hier das Listing:

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        100001
   IODev      HMLAN1
   NAME       VIR_TC1
   NR         324
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 TC1_1
   protCmdDel 7
   protResndFail 7 last_at:2014-04-08 08:40:40
   protSnd    7 last_at:2014-04-08 08:40:30
   protState  CMDs_done_Errors:1
   Readings:
     2014-04-08 08:40:40   state           MISSING ACK
   Helper:
     rxType     1
     Io:
       newChn     +100001,00,01,1E
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       dev        1
Attributes:
   autoReadReg 4_reqStatus
   expert     2_full
   model      virtual_1
   msgRepeat  0
   peerIDs   
   subType    virtual


Der Stellmotor beharrt unverbesserlich auf seinen 15%...

[frank]

Config drücken? Meinst du die Anlerntaste?

ja.

Inzwischen habe ich auch ein "MISSING ACK in meinem Virtuellen Schalter.

wenn dein vd immer noch nicht gepeert ist, muss das auch so sein. 

also vd mit vtc peeren.

Code Auswählen Erweitern

set CUL_HM_HM_CC_VD_1F914E clear msgEvents
set TC1 peerChan 0 CUL_HM_HM_CC_VD_1F914E single set actor
anlerntaste vd 3 sec drücken
set CUL_HM_HM_CC_VD_1F914E getConfig
anlerntaste vd 3 sec drücken


erst wenn der peer im attribut peerIds eingetragen ist bist du fertig. dann sollte es funktionieren. anschliessend alles sichern mit save config.

gruss frank

[dan1180]

Hallo Frank,

das peeren scheint funktioniert zu haben. Dake. Lag der Fehler daran, dass vorher kein "...set actor" beim peer-Befehl gesetzt wurde?

Ein paar kleine Fragen hätte ich da aber noch...

1.
Warum brauch ich den virtuellen Aktor? Warum kann ich das Ventil nicht direkt am gepairten VD steuern und dort mittels Programmierung für verschiedene Vorgaben gewisse Ventilstellungen vorgeben
(z.B. Solltemperatur TC-IT < Isttemperatur TC-IT -> Ventilstellung 50%)?

2.
Kann mir jemand sagen, in welchen Intervallen der VD "aufwacht" und sich sein todo anschaut? Holt er sich aktiv die anstehenden CMDs ab oder muss FHEM diese zufällig auch zu der Zeit senden?

3.
Ich möchte ja echt nicht nerven und ich habe es auch akzeptiert. Warum kann der TC-IT nciht mit dem CC-VD gepeert werden? Er hat doch auch einen _Climate Kanal, wie der CC-TC? Ich möchte es nur verstehen.

Vielen Lieben Dank an euch alle!

[frank]

Lag der Fehler daran, dass vorher kein "...set actor" beim peer-Befehl gesetzt wurde?

siehe einsteiger.doc! "...single set" oder "...single set both" setzt die peers im actor und im remote. da der peer im remote bereits eingetragen war, musste nur noch im actor gesetzt werden.

Warum brauch ich den virtuellen Aktor? Warum kann ich das Ventil nicht direkt am gepairten VD steuern und dort mittels Programmierung für verschiedene Vorgaben gewisse Ventilstellungen vorgeben
(z.B. Solltemperatur TC-IT < Isttemperatur TC-IT -> Ventilstellung 50%)?

du brauchst keinen virtuellen actor, sondern ein virtuellen remote. der actor ist dein vd. warum ein vd nur von einem hm-cc-tc gesteuert werden kann, kann dir nur eq3 erklären.

Kann mir jemand sagen, in welchen Intervallen der VD "aufwacht" und sich sein todo anschaut? Holt er sich aktiv die anstehenden CMDs ab oder muss FHEM diese zufällig auch zu der Zeit senden?

120 - 180 sekunden. der rythmus ist nicht konstant. siehe thread tc-emulieren. der vd wacht in diesen abständen für 250ms auf und erwartet dann seine befehle. wenn das 6 mal hintereinander nicht klappt schäft der vd ganz ein. nach ca 60 min kann er reannimiert werden.

Ich möchte ja echt nicht nerven und ich habe es auch akzeptiert.

das ist gut. 

Warum kann der TC-IT nciht mit dem CC-VD gepeert werden?

siehe 1. peeren könnte durchaus klappen.  der it wird wahrscheinlich nicht in dem augenblick, wenn der vd kurz aufwacht, den richtigen befehl senden. probieren geht über studieren.

ich nutze meine vd auch in kombination mit vtc. zusätzlich verwende ich noch das modul pid20 als regler. funktioniert bestens. sei froh, dass fhem seit kurzem überhaupt in der lage ist, den vd zu steuern!

gruss frank

[dan1180]

Hallo Frank,

nochmal vielen Dank für die ausführlichen Antworten. Das heißt also theoretisch könnte der TC-IT mit dem CC-VD funktionieren. Es muss nur dann der Befehl gesendet werden, wenn der VD zuhört (sendet der CC-TC in kürzeren Abständen?).

Da ich jedoch meine Befehle alle über FHEM sende (pair und peer) und die FHEM-Befehle ja (über den VTC) "rechtzeitig" ankommen, könnte das doch eigentlich klappen?!? Das werd ich gleich mal probieren...

Der VTC funktioniert jetzt bestens. Nur springt mein VD nach einer gewissen Zeit (wahrscheinlich 6x erfolgloses hinhören) auf 15% zurück. Wie kann ich das noch vermeiden?

[frank]

Das heißt also theoretisch könnte der TC-IT mit dem CC-VD funktionieren.

das war ironie! 
du kannst sie bestimmt peeren, doch wird der it den vd nicht steuern können. dazu müsste der it ventilpositionen senden. soweit ich das verfolgt habe, kann der aber nur temperaturen senden. er hat aber keinen regler der aus soll und ist eine ventilposition berechnet.

gruss frank

[dan1180]

Und dafür brauch ich dann spätestens einen VTC? Oder kann ich die Regelung direkt im VD programmieren?
Was mach ich nun mit meinem VD wenn er sich nach einer Zeit x wieder schlafen legt?

...und Ironie ist bei einem Anfänger wie mir immer gefährlich 

[frank]

Der VTC funktioniert jetzt bestens. Nur springt mein VD nach einer gewissen Zeit (wahrscheinlich 6x erfolgloses hinhören) auf 15% zurück. Wie kann ich das noch vermeiden?

da müsstest du mal rohmessages aus fhem.log posten.

Code Auswählen Erweitern

attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs VIR_TC1,CUL_HM_HM_CC_VD_1F914E
attr TC1 verbose 5

Und dafür brauch ich dann mindestens einen VTC? Oder kann ich die Regelung direkt im VD programmieren?

der virtuelle tc ist dafür gedacht den realen vd mit entsprechenden befehlen zu passenden momenten zu steuern. du übergibst dem vtc eine ventilstellung und dieser kann sie dann dem vd mitteilen.
der vd hat keine regelung. das ist nur ein stellglied. er bekommt eine sollposition und stellt diese dann ein.

eine regelung berechnet aus einer ist- und solltemperatur eine ventilposition. das kannst du mit einem fhem-modul machen. da gibt es zum beispiel das modul pid20. suche mal nach pid20 im forum. dem regelmodul gibst du soll und ist temperatur. dieses berechnet dann eine ventilposition, die dem vtc übergeben wird.

gruss frank

[frank]

ich hätte da noch einen tipp.

ich spekuliere mal, dass du den thread http://forum.fhem.de/index.php/topic,18193.msg120864.html#msg120864 noch nicht vollständig durchgearbeitet hast. 

daher denke ich das einschlafen deines vd ist entweder nach fhem reboot oder ähnlichem geschehen. damit fhem mit dem vd fehlerfrei kommunizieren kann, wird der lezte erfolgreiche kommunikationszeitpunkt zur berechnung des neuen zeitpunktes benötigt. dieser wird normalerweise nur in fhem in einem normalerweise unsichtbaren reading (.next) zwischengepeichert. um nach reboot immer einen aktuellen wert zu haben, muss diese variable ständig gespeichert werden.

ich mache dies durch einfügen des folgenden codes in fhem.cfg

Code Auswählen Erweitern

define AutoSave at +*00:15:00 {\
{BlockingCall("WriteStatefile", "","", 30,"", "")}\
}
attr AutoSave room 99_System


dann kann der vd sogar 5min stromausfall meines servers überleben.

gruss frank

[dan1180]

Die Rohmessages? Hab ich noch nie gebraucht

ISt das der Teil des fhem.log, der nach dem verbose 1 geschreiben wird? Der sieht so aus:

Code Auswählen Erweitern


2014.04.08 18:25:32 4: HTTP FHEMWEB:192.168.2.103:51931 GET /fhem&cmd=attr+global+verbose+1
2014.04.08 18:25:32 5: Cmd: >attr global verbose 1<
2014.04.08 18:25:58.533 1: 192.168.2.151:1000 reappeared (HMLAN1)
2014.04.08 18:25:58.547 1: HMLAN_Parse: HMLAN1 new condition init
2014.04.08 18:25:58.693 1: HMLAN_Parse: HMLAN1 new condition ok
2014.04.08 18:26:22.092 5: CUL_HM TC1_1 m:177 ->178 t:1396974379.70243->1396974511.95243  M:1396974382.09205 :132.25
2014.04.08 18:26:22.100 0: HMLAN_Send:  HMLAN1 S:S42296D58 stat:  00 t:00000000 d:01 r:42296D58 m:B2 A258 100001 1F914E 0080
2014.04.08 18:26:34.267 0: HMLAN_Parse: HMLAN1 R:R42296D58 stat:0008 t:00000000 d:FF r:7FFF     m:B2 A258 100001 1F914E 0080
2014.04.08 18:26:34.271 0: HMLAN_Parse: HMLAN1 no ACK from 1F914E
2014.04.08 18:26:41.512 5: CUL_HM TC1_1 virtualTC use fail-timer


Ansonsten bitte kurze Erläuterung.

Zu deinem Tipp...nein, den Beitrag kannte ich noch gar nicht. Mein Problem mit Beiträgen dieser Art ist, glaube ich, dass ich nicht nach Worten wie "emulieren" suche
Werd ihn mir auf jeden Fall mal ansehen, Danke.

Was ich aber gleich sagen kann ist, dass das Einschlafen nicht nach einen Neustart passiert ist.
Peeren -> Ventilpos. auf 50% -> warten -> Einschlafen...

[martinp876]

Die Rohmessages?

http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen

Peeren -> Ventilpos. auf 50% -> warten -> Einschlafen...

der VD hält einige Zeit tapfer durch bis er aufgibt. Also in den Rohmessages suhen (in den Readings stehen auch hinweisen)

[dan1180]

Hallo Martin,

die Anleitung aus dem Wikli hatte mir Frank schon gepostet, danke. Dort steht aber leider auch nicht wirklich welches der relevante Teil ist, den ich aus meinem Log dann kopieren soll.
Seltsamerweise ist mein VD mittlerweile wieder wach  Nachdem ich ihn vor gut 3 Stunden schlafend auf 15% verlassen hatte steht er mittlerweile wieder auf den zuletzt eingestellten 50%...und ich hab nix gemacht...wirklich!
Hab ihm jetzt befohlen auf 20% zu gehen und will sehen, was er bis morgen macht. Mittlerweile werde ich wohl noch dem ein oder anderen Hinweis von euch nachgehen und kräftig Beiträge lesen. Ich will dieses Ding in den Griff bekommen!
Wäre nett wenn du mir noch 1-2 Zeilen zur Rohmessage schicken könntest. Oder einen link zu ner Erklärung. Vielen Dnak dafür!

[martinp876]

Beachte das Verfahen:
der VD wacht leicht unregelmäßig auf - FHEM berechnet dies und sendet die Einstellungen. Wenn die beiden ausser tritt geraten dauert es etwas - irgendwann beginnt der VD quasi zu suchen.
=> normal kommen sie nicht ausser tritt
=> reboots können so etwas hervorrufen
=> nach einiger zeit (etliche Minuten) sollten sie sich wieder fangen

Du solltest valveCtrl beobachten - da steht drin, ob du noch Synchron bist

[dan1180]

Hallo Martin,

in einem Punkt kann ich dir Recht geben...der VD fängt sich immer wieder. Dummerweise fällt er auch ständig wieder in den Error-Moder (ValvePos 15%). Eine Möglichkeit, dass er wieder zu sich kommt ist das (kurze) Drücken der Anlerntaste. Was ja irgendwie logisch ist wenn er manuell geweckt wird.
valveCtrl hat mir in der Fehlersituation auch immer einen Fehler angezeigt. Seit gut einer halben Stunde hab ich jetzt gar kein Reading namens valveCtrl mehr...aber im Moment (nach Drücken der Anlerntaste) tut auch alles.

Würde euch gerne mal noch über die Rohmessage schauen lassen, wenn mir jemand erklären kann wie ich die genau hier posten kann...

Danke.