TC emulieren

[frank]

hallo martin,

achtung - zu früh bringt auch nichts.
Der HMLAN liefert ein Präzises Timing - da sehe ich überhaupt keine Probleme.

wenn ich auf ein climateEvent eines realen tc, das vom hmlan empfangen wird, so schnell als möglich versuche zu reagieren, kann ich die antwort doch niemals "zu früh" senden.
es könnte nur zu früh werden, wenn ich nicht "reagiere", sondern "antizipiere" und aus verdacht eine antwort sende.

ich habe noch mal eine tc/vvd-kombi mit dem cul gepaired und den hmlan zum monitoren verwendet. mit deinem 00_cul_patch ermittle ich aus den hmlan zeitstempeln reaktionszeiten von 175ms bis 180ms. eventuell kann man sagen, dass dadurch 1-2ms gewonnen werden können. mein "vorziehen" des "push @ack" bringt, wenn überhaupt, nur 0-1ms.

Code Auswählen Erweitern

msgParseDly       min:-3968 max:6638 last:121 cnt:707

ist msgParseDelay die verzögerung vom hmlan-zeitstempel zum fhem-zeitstempel?
ich hatte den hmlan irgendwann währed der neuen tests stromlos gemacht, um zu resetten.

schön wär mal eine idee mit vielleicht 20ms zeitgewinn!
meinen spezielllen tc bestücke ich ab sofort nur nöch mit gebrauchten batterien, dann fühlt er sich wohl und versteht fhem!

gruss frank

[frank]

hallo martin,

wäre es zuviel verlangt, beim virtuellen tc, das reading valveCtrl als event zu posten?
dann könnte ich das schön überwachen!

gruss frank

[martinp876]

Hallo Frank,

Der TC setzt im Ventil ValveDesired - reicht dies nicht?
oh - ich denke, ich setze dies im Device (da ein VD immer ein device ist). werde ich einmal anpassen...

so schnell als möglich versuche zu reagieren, kann ich die antwort doch niemals "zu früh" senden.

das trifft evtl auf ein ack zu. Kommandos und andere reaktionen darf man nicht so schnell als möglich senden. 100ms sind gefordert. Kann man nichts machen.

aus den hmlan zeitstempeln reaktionszeiten von 175ms bis 180ms.

dann klappt es nicht. Rudi hat die Änderung bereits eingecheckt. Kannst du dies noch einmal loggen? Wenn du mit CUL arbeitest.

mein "vorziehen" des "push @ack" bringt, wenn überhaupt, nur 0-1ms.

klar - das timing wird im IO gemacht.

ist msgParseDelay die verzögerung vom hmlan-zeitstempel zum fhem-zeitstempel?

ja. Wenn du 6 sec hat ist dies durchaus möglich - du solltest mit apptime suchen, ob ein Prozess so lange dauert. Da habe ich schon mehrere gefunden.

Gruss Martin

[frank]

hallo martin,

ich habe jetzt mal einen realen tc mit je einem realen und virtuellen vd gepeert und alle beteiligten devices an den cul868 gekoppelt. den funkverkehr habe ich mit einem "unbeteiligten" hmlan aufgezeichnet. die vom tc erzeugten climateEvents und die antworten von vd und vvd, inklusive der berechneten reaktionszeiten siehst du hier:

Code Auswählen Erweitern

reaktionszeiten von vd,vvd auf climateEvent von tc
--------------------------------------------------

versuchsaufbau:
---------------------------------------------------
tc,vd: mit cul868 gepairt
tc,vd,vvd: IODev cul868
tc mit vd,vvd gepeert

hmlan(monitor):123ABC
cul868:C1C1C1
tc:1BF81B
vd:1C4E25
vvd:D4D4D4

messergebnisse:
---------------------------------------------------
2014.01.26 14:33:38.068 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:040AD87B d:FF r:FFB9     m:5E A258 1BF81B 1C4E25 00FE
2014.01.26 14:33:38.080 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:040AD8FB d:FF r:FFC0     m:5E 8202 1C4E25 1BF81B 0101C60025
67819643
67819771
128ms ### realer vd ###

2014.01.26 14:36:21.728 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:040D5743 d:FF r:FFBC     m:5F A258 1BF81B D4D4D4 00FE
2014.01.26 14:36:21.740 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:040D57F7 d:FF r:FFDD     m:5F 8202 D4D4D4 1BF81B 0101C60000
67983171
67983351
180ms ### virtueller vd ###

2014.01.26 14:38:50.565 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:040F9D64 d:FF r:FFBB     m:60 A258 1BF81B 1C4E25 00FE
2014.01.26 14:38:50.578 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:040F9DE4 d:FF r:FFBF     m:60 8202 1C4E25 1BF81B 0101C60024
68132196
68132324
128ms ### realer vd ###

2014.01.26 14:41:04.971 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0411ABDA d:FF r:FFBB     m:61 A258 1BF81B D4D4D4 00FE
2014.01.26 14:41:06.001 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:0411AD4B d:FF r:FFDD     m:61 8202 D4D4D4 1BF81B 0101C60000
68266970
68267339
369ms ### virtueller vd ###

2014.01.26 14:43:05.625 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:041381A9 d:FF r:FFBB     m:62 A258 1BF81B 1C4E25 00FE
2014.01.26 14:43:05.642 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0413822A d:FF r:FFBE     m:62 8202 1C4E25 1BF81B 0101C60026
68387241
68387370
129ms ### realer vd ###

2014.01.26 14:45:56.587 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:041618DB d:FF r:FFBD     m:63 A258 1BF81B D4D4D4 00FE
2014.01.26 14:45:56.616 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:04161B0D d:FF r:FFDD     m:63 8202 D4D4D4 1BF81B 0101C60000
68557019
68557581
562ms ### virtueller vd ###

2014.01.26 14:48:30.841 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:04187862 d:FF r:FFBC     m:64 A258 1BF81B 1C4E25 00FE
2014.01.26 14:48:30.854 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:041878E3 d:FF r:FFBD     m:64 8202 1C4E25 1BF81B 0101C60024
68712546
68712675
129ms ### realer vd ###

2014.01.26 14:50:52.006 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:041A9F42 d:FF r:FFBD     m:65 A258 1BF81B D4D4D4 00FE
2014.01.26 14:50:52.019 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:041A9FF5 d:FF r:FFDD     m:65 8202 D4D4D4 1BF81B 0101C60000
68853570
68853749
179ms ### virtueller vd ###

2014.01.26 14:55:54.366 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:041F3D18 d:FF r:FFBB     m:67 A258 1BF81B 1C4E25 00FE
2014.01.26 14:55:54.379 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:041F3D99 d:FF r:FFBF     m:67 8202 1C4E25 1BF81B 0101C60027
69156120
69156249
129ms ### realer vd ###

2014.01.26 14:58:36.555 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0421B50A d:FF r:FFBD     m:68 A258 1BF81B D4D4D4 00FE
2014.01.26 14:58:36.568 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:0421B623 d:FF r:FFDD     m:68 8202 D4D4D4 1BF81B 0101C60000
69317898
69318179
281ms ### virtueller vd ###

2014.01.26 15:01:07.560 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0423F455 d:FF r:FFBF     m:69 A258 1BF81B 1C4E25 00FE
2014.01.26 15:01:08.344 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0423F4D6 d:FF r:FFBB     m:69 8202 1C4E25 1BF81B 0101C6002C
69465173
69465302
129ms ### realer vd ###

2014.01.26 15:03:15.664 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0425FAF9 d:FF r:FFBE     m:6A A258 1BF81B D4D4D4 00FE
2014.01.26 15:03:16.705 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:0425FC58 d:FF r:FFDC     m:6A 8202 D4D4D4 1BF81B 0101C60000
69597945
69598296
351ms ### virtueller vd ###

2014.01.26 15:06:18.905 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0428C3FC d:FF r:FFBE     m:6B A258 1BF81B 1C4E25 00FE
2014.01.26 15:06:19.440 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0428C47D d:FF r:FFBC     m:6B 8202 1C4E25 1BF81B 0101C6002C
69780476
69780605
129ms ### realer vd ###

2014.01.26 15:09:06.975 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:042B5458 d:FF r:FFBE     m:6C A258 1BF81B D4D4D4 00FE
2014.01.26 15:09:06.988 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:042B5557 d:FF r:FFDC     m:6C 8202 D4D4D4 1BF81B 0101C60000
69948504
69948759
255ms ### virtueller vd ###

2014.01.26 15:11:40.158 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:042DAC0E d:FF r:FFBE     m:6D A258 1BF81B 1C4E25 00FE
2014.01.26 15:11:40.171 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:042DAC8F d:FF r:FFBA     m:6D 8202 1C4E25 1BF81B 0101C6002D
70102030
70102159
129ms ### realer vd ###

2014.01.26 15:13:59.613 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:042FCC17 d:FF r:FFBD     m:6E A258 1BF81B D4D4D4 00FE
2014.01.26 15:13:59.625 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:042FCD06 d:FF r:FFDD     m:6E 8202 D4D4D4 1BF81B 0101C60000
70241303
70241542
239ms ### virtueller vd ###

2014.01.26 15:16:04.147 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0431B37A d:FF r:FFBD     m:6F A258 1BF81B 1C4E25 00FE
2014.01.26 15:16:04.159 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0431B3FB d:FF r:FFBE     m:6F 8202 1C4E25 1BF81B 0101C6002F
70366074
70366203
129ms ### realer vd ###

2014.01.26 15:18:58.815 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:04345C41 d:FF r:FFBD     m:70 A258 1BF81B D4D4D4 00FE
2014.01.26 15:18:59.573 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:043460E7 d:FF r:FFDD     m:70 8202 D4D4D4 1BF81B 0101C60000
70540353
70541543
190ms ### virtueller vd ###

2014.01.26 15:21:38.145 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:0436CC62 d:FF r:FFBB     m:71 A258 1BF81B 1C4E25 00FE
2014.01.26 15:21:38.159 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0436CCE3 d:FF r:FFBF     m:71 8202 1C4E25 1BF81B 0101C60038
70700130
70700259
129ms ### realer vd ###

2014.01.26 15:24:03.819 0: HMLAN_Parse: HMLAN1 R:E1BF81B   stat:0000 t:043904D6 d:FF r:FFBF     m:72 A258 1BF81B D4D4D4 00FE
2014.01.26 15:24:03.832 0: HMLAN_Parse: HMLAN1 R:ED4D4D4   stat:0000 t:04390587 d:FF r:FFDC     m:72 8202 D4D4D4 1BF81B 0101C60000
70845654
70845831
177ms ### virtueller vd ###

Der TC setzt im Ventil ValveDesired - reicht dies nicht?
oh - ich denke, ich setze dies im Device (da ein VD immer ein device ist). werde ich einmal anpassen...

ich würde gerne auf "ok,miss_1,...,miss_5,lost" reagieren.


gruss frank

[martinp876]

Hi Frank,

meine CUL antwortet in 40ms - sehr konstant.
hast du schon einmal geprüft, was apptime zu deinem System sagt?

ich würde gerne auf "ok,miss_1,...,miss_5,lost" reagieren.

schwierig - oder habe ich einen denkfehler? Wenn der reale Tc  sendet und wir antworten kann es zu spät gewesen sein - oder auch nicht. Das ist kaffeesatzlesen.  Wie soll ich feststellen, ob etwas verpasst wurde? Wenn der TC nicht mehr sendet?

Gruss Martin

[frank]

hallo martin,

schwierig - oder habe ich einen denkfehler? Wenn der reale Tc  sendet und wir antworten kann es zu spät gewesen sein - oder auch nicht. Das ist kaffeesatzlesen.  Wie soll ich feststellen, ob etwas verpasst wurde? Wenn der TC nicht mehr sendet?

langsam.
ich würde gerne auf änderungen des readings "valveCtrl" vom "virtuellen tc" reagieren, um zu erkennen, ob der "reale vd" schon eingeschlafen ist (valveCtrl=lost). oder ob er mit hoher wahrscheinlichkeit (valveCtrl=miss_5) gleich einschlafen wird.
das reading haben wir ja schon. es wird halt kein event gepostet, so dass ich bequem über ein notify darauf zugreifen könnte.

meine CUL antwortet in 40ms - sehr konstant.
hast du schon einmal geprüft, was apptime zu deinem System sagt?

sind das die antworten eines virtuellen vd auf die climateEvents eines realen tc?

gruss frank

[martinp876]

edit: Bei mir kommen sie events - sollte man triggern können.

Hi Frank

es wird halt kein event gepostet, so dass ich bequem über ein notify darauf zugreifen könnte.

ui - ist aber so eingestellt. Mal untersuchen - bin schon einmal reingefallen, das in fhem.pl einfach das triggern unterdrückt wird.

werde einmal nachsehen.

sind das die antworten eines virtuellen vd auf die climateEvents eines realen tc?

korrekt
Gruss Martin

[frank]

hallo martin,

auf der verzweifelten suche nach deinen 40ms, hat ein "komplettes" fhem update, inklusive reset der fritzbox, alle probleme gelöst (ein einfaches reload 00_CUL.pm reicht vielleicht nicht aus).

als zugabe kamen sogar noch die valveCtrl-events.

alle virtuellen und realen devices hängen wieder am hmlan. alles läuft wie gewünscht.

vielen, vielen, ...dank
gruss frank

[eldrik]

Hi,

vorab eine tolle Leistung die hier betrieben worden ist!

Ich folge dem Thread nun schon ein Weile, ist es mit der jetzigen Version nunmehr möglich:

- einen oder mehrere TC zu emulieren und hierdurch die VDs zu betreiben?
- externe nicht HM Temperatursensoren für den virtuellen TC zu benutzen?
- externe nicht HM Fensterkontakte für den virtuellen TC zu benutzen, zur Absenkung der Temperatur bei offenen Fenster?
- wie ist die Zuverlässigkeit?

Greetz
Eldrik

[martinp876]

Hi Eldrik,

- einen oder mehrere TC zu emulieren und hierdurch die VDs zu betreiben?

ja

- externe nicht HM Temperatursensoren für den virtuellen TC zu benutzen?

ja  - regelalgorythmus musst du selbst schreiben

- externe nicht HM Fensterkontakte für den virtuellen TC zu benutzen, zur Absenkung der Temperatur bei offenen Fenster?

ja..  - wenn ist eine einfache temp-absenkung - musst du selbst bauen und in die Regelung einfließen lassen

- wie ist die Zuverlässigkeit?

hängt von System ab.
Limitierungen:
HMLAN sendekapazität - HMLAN wird irgendwann abschalten , wen zu viel gesendet wurde. Beobachte hierzu die Performance indikatoren
die Systemlast könnte zu verzögerungen führen, die zu message-loss führen. Einfache Fehler kann das System ab - wenn dein System "dicht" wird könnte es knapp werden .

Gruss Martin

[frank]

hallo eldrik,

- einen oder mehrere TC zu emulieren und hierdurch die VDs zu betreiben?

die tc-emulation ist eigentlich nur ein virtuelles hm-device (vtc), dass in der lage ist, einen realen hm-cc-vd (vd) zu steuern. du setzt den vtc auf den gewünschten wert und dieser sorgt dann dafür, dass der vd solange in der gewünschten position verbleibt, bis du den wert veränderst.

mit welchen werten du den vtc versorgst, liegt in deiner hand. du kannst dir nun eine funktion zusammenbauen, die in abhängigkeit unterschiedlichster daten (tsoll, tist, fenster, uhrzeit, anwesenheit, sonnenstand, ...usw), eine für dich brauchbare öffnungsposition liefert.

ich steuere meine 4 vd seit ein paar tagen über fhem mit 4 vtc sehr erfolgreich. bis dahin wurde das von 4 realen tc nicht so erfolgreich durchgeführt. nun benutze ich die von den tc "empfohlenen" vd-positionen, wenn sie mir zusagen. ansonsten werden sie nach meinen wünschen verändert, bevor sie, über den umweg der 4 vtc, an die realen vd gesendet werden.

ein realer vd muss spätestens alle 10-15 minuten eine erfolgreiche kommunikation mit seinem positionsgeber haben, damit er nicht einschläft und die error-position einstellt. sollte dies dennoch geschehen, so wacht der vd erst nach einer guten stunde wieder auf, und versucht erneut mit seinem positionsgeber zu kommunizieren. wenn das erfolgreich verläuft, ist alles wieder normal. das gilt, sowohl für den virtuellen tc, als auch für den realen tc als positionsgeber.

aus dieser beschreibung musst du nun selber die vor- oder nachteile in bezug zu deinem system bestimmen.

gruss frank

[martinp876]

Hallo Frank,

es gibt Probleme mit dem "Schnellen ACK". Einige Devices vertragen das nicht. Daher ist die Frage, ob es mit 50ms auch klappt.

anbei eine Datei mit 50ms delay für ACKs. Wäre gut, wenn du diese testen könntest. Das wäre ein kompromiss, der hoffentlich alle Glücklich macht.

Gruss Martin

[frank]

hallo martin,

betrifft mich das denn überhaupt? ich nutze eigentlich nur hmlan.

den cul868 hatte ich zwischenzeitlich nur eingebaut , weil der hmlan nicht funktionierte. ich hatte die hoffnung mit cul könnte es besser werden. zusätzlich gab es dann die möglichkeit mit hmlan als monitor zu schauen.

nachdem du 40ms gemessen hattest, habe ich ein komplettes update gemacht und alles resettet. anschliessend zwei messungen mit ca. 80ms aufgezeichnet und dann sofort auf hmlan zurückgewechselt.

seitdem läuft alles einwandfrei mit hmlan.

aber ich teste das trotzdem gleich mal. morgen weiss ich dann mit sicherheit genaues.

gruss frank

[frank]

kurzer erfahrungsbericht mit 4 vd, die über fhem (vtc) gesteuert werden

seit einer knappen woche steuer ich meine vd über fhem und versorge sie entweder mit den werten, die mir die realen tc bieten, oder mit eigenen werten. dabei hat sich in den letzten tagen gezeigt, dass diese vorgehensweise so nicht funktioniert, da der tc, die durch meine ventilstellungen herbeigeführten temperaturänderungen auf seine berechneten ventilstellungen bezieht. weil ich häufig 100% setze, glaubt der tc langsam, dass er mit 80% dasselbe leisten kann. somit habe ich nun den regler des tc vollkommen aus der regelung entfernen müssen. das übernimmt momentan testweise das modul "PID20".

das eigentliche ansteuern der vd läuft hingegen einwandfrei. als beispiel habe ich mal einen plot von heute angehängt. zu sehen sind die "ergebnisse" der kommunikation zwischen vd und vtc (reading:valveCtrl vom vtc). wenn der vtc einen steuerbefehl an den vd abgesetzt hat und der vtc daraufhin eine antwort empfangen hat, ist die kommunikation "ok". es gibt nichts zu sehen (kein y-wert). bei einer 100%-igen kommunikation wären also gar keine ausschläge vorhanden.

zu erkennen sind also alle misslungenen kommunikationen. und zwar die anzahl der in folge misslungenen kommunikationen. zb 2 mal in folge keine antwort erhalten, ergibt ein "miss_2". bei 6 fehlenden antworten nacheinander ergibt sich ein "lost", da sich nun der vd verabschiedet und einschläft (21.30 SZ). wenn man nichts unternimmt, wacht er nach gut 60 min wieder auf, und kann normal weiterarbeiten. zu dieser zeit hatte ich meine fritzbox resettet. bei den anderen 3 vd habe ich noch rechtzeitig die anlerntaste für 3sec gedrückt, woraufhin die kommunikationen weiterlaufen konnten. ohne einschlafen der vd.

generell gibt es eigentlich nur gelegentlich "einfache" (miss_1) fehlkommunikationen. manchmal "miss_2" und sehr selten"miss_3" und höher. diese werden hauptsächlich durch verzögerungen des programmablaufs in meiner fritzbox erzeugt. interessant wäre ein vergleich mit einem wenig belasteten system mit mehr power.
in der ganzen zeit sind aber erst 2 "lost" ereignisse bei 4 vd aufgetreten! bis hierher bin ich mit dem zwischenergebnis sehr zu frieden!

@martin
eigentlich müsste es doch möglich sein, die kommunikation nach einem reset am leben zu halten? werden die berechneten kommunikationszeitpunkte nicht gespeichert und über den reset gerettet?

gruss frank

[frank]

hallo martin,

die 00_CUL.pm läuft bis jetzt ohne erkennbare auffälligkeiten (14 std). wie bereits gesagt, nutze ich zur zeit keinen cul868 für homematic.

gruss frank