TC emulieren

frank · 19 Januar 2014, 13:48:48

hallo martin,

Zitatwarum nicht den timestamp prüfen. mit jedem ack auf ein setzen wird u.a. ValvePosition geändert. ReadingsTimestamp muss sich also geändert haben. Es müsste noch nicht einmal auf den Inhalt geprüft werden, nur auf gleichheit.

klingt gut. auf $virtDeviceState zu prüfen bringt natürlich bei mehreren vd nichts. mehrere vd hatte ich bisher gar nicht auf der rechnung!

ZitatAllerdings verkompliziert sich das alles dann, da ein ACK für jeden VD auf der Liste geprüft werden muss und die Timer auseinander laufen. Faktisch muss man also für jeden VD einen timer laufen lassen, nicht für jeden TC. Oder den TC timer entsprechend berechnen... dass er immer für den nächsten VD in seiner Liste aufgerüfen wird.

ich denke am unabhängigsten ist man, wenn jeder vd einen eigenen timer bekommt. die laufen dann wahrscheinlich nicht nur auseinander, sondern überholen sich sogar gegenseitig je nach toleranzen. batteriewechsel, neu anlernen und funkprobleme kommen auch noch dazu.

zum einfügen der prüfungssequenz ist mir doch noch etwas eingefallen. ich würde nun die funktion "CUL_HM_valvePosUpdt(@)" teilen.

die erste funktion "CUL_HM_valvePosUpdt(@)" löst das climateEvent aus, wie bisher. am ende ruft sie sich aber nicht selber über den internalTimer auf, sondern die zweite funktion "CUL_HM_valvePosTiming(@)" über einen festen internalTimer mit zb 10 sekunden.
hier wird dann die prüfung vorgenommen, das timing berechnet und zum schluss über einen weiteren internalTimer mit dann exaktem timing die erste funktion "CUL_HM_valvePosUpdt(@)" aufgerufen.

gruss frank

frank · 19 Januar 2014, 16:32:35

hallo martin,

ich habe noch folgendes in zeile 3111 eingefügt, direckt vor dem ersten aufruf von "CUL_HM_valvePosUpdt". sonst "überschlägt" sich die funktion!

Code Auswählen

$hash->{helper}{vd}{next} = gettimeofday();

nur mal so am rande:
ich habe meinen test-vd jetzt mal über ein notify an einen tc gekoppelt. der folgt diesem jetzt tapfer. wer 5 oder mehr vd ansteuern will hat keine probleme mehr. oder negative und funktionale offsets. vielleicht auch nur in bestimmten situationen mitlaufen lassen. möglichkeiten ohne ende!

gruss frank

martinp876 · 19 Januar 2014, 17:12:08

Hallo Frank,

mal sehen, dass ich schritt halten kann.

Ich habe einmal alles implementiert wie ich es verstanden habe.
1) dass ein channel nur einen VD handeln kann ist noch nicht eingebaut - können wir später nachholen
2) welchen vorteil siehst du darin, die Funktion zu splitten? Performance gründe können es nicht sein, da es schlussendlich mehr performance kostet - ein weiterer Timer,... und bei vielen TCs viele Timer

mein VD läuft noch nicht rund... aber ich habe nicht viel getestet.

Gruss Martin

frank · 19 Januar 2014, 18:16:33

hallo martin,

Zitat2) welchen vorteil siehst du darin, die Funktion zu splitten? Performance gründe können es nicht sein, da es schlussendlich mehr performance kostet - ein weiterer Timer,... und bei vielen TCs viele Timer

als ich das geschrieben habe, hatte ich keine vorteile im splitten gesehen. ich hätte es nur mit meinem wissen so am einfachsten umsetzen können. da wir einen moment warten müssen, bis auch sicher alles verarbeitet ist, um prüfen zu können, ist diese idee entstanden.

nach einem neustart meiner fritzbox habe ich unglaubliche verzögerungen. siehe anhang. mehrere male zwischen 120-130 sekunden!!!

martinp876 · 19 Januar 2014, 18:26:26

files habe ich gerade eingecheckt.

nun - FHEM ist langsam - der neustart ist aufwendig. Auch sonst haben wir immer wieder kritisches timing - an vielen Stellen.

Du kannst apptime nutzen um einen überblock zu bekommen - beim Neustart ist es natürlich nicht von Anfang an dabei - aber du kannst es aus fhem.cfg starten, gleich zu beginn.

An der einen oder anderen Stelle ist der User schuld... macht also sinn, einmal zu schauen.

Gruss Martin

frank · 19 Januar 2014, 21:12:48

hallo martin,

deine prüfung ist leider an der falschen stelle. sie muss hier her:

Code Auswählen

  CUL_HM_ProcessCmdStack($hash);

  ##########   warten     ##########

  ##########   pruefung   ##########

  InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);

an deiner stelle prüfst du zb m05 (msgNbr05), nimmst die verzögerung von m06 und veränderst die eventTime von m07.

sagen wir mal m05 war ok. m06 hat 3000ms verzögerung. dann wird diese verzögerung bei m07 auch nicht berücksichtigt und fällt unter den tisch. der vd schläft ein. selbst wenn keine weiteren verzögerungen dazukommen, kann der vd das nicht mehr reparieren!

sind es nur 1000ms schaft der vd es gerade noch beim 5. versuch:

Code Auswählen

2014.01.19 20:29:15.050 0: HMLAN_Send:  HMLAN1 S:SABFA786B stat:  00 t:00000000 d:01 r:ABFA786B m:1B A258 A1A1A1 1C4E25 00FA
2014.01.19 20:29:15.239 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:2F3C13D2 d:FF r:FFA6     m:1B 8202 1C4E25 A1A1A1 0101C40057
2014.01.19 20:29:15.678 0: HMLAN_Parse: HMLAN1 R:RABFA786B stat:0008 t:00000000 d:FF r:7FFF     m:1B A258 A1A1A1 1C4E25 00FA
2014.01.19 20:29:15.681 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 20:32:06.654 3: VD-timing Critical ##### diff:1108
2014.01.19 20:32:06.660 0: HMLAN_Send:  HMLAN1 S:SABFD16C5 stat:  00 t:00000000 d:01 r:ABFD16C5 m:1C A258 A1A1A1 1C4E25 00FA
2014.01.19 20:32:07.267 0: HMLAN_Parse: HMLAN1 R:RABFD16C5 stat:0008 t:00000000 d:FF r:7FFF     m:1C A258 A1A1A1 1C4E25 00FA
2014.01.19 20:32:07.270 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 20:34:42.671 0: HMLAN_Send:  HMLAN1 S:SABFF7830 stat:  00 t:00000000 d:01 r:ABFF7830 m:1D A258 A1A1A1 1C4E25 00FA
2014.01.19 20:34:43.279 0: HMLAN_Parse: HMLAN1 R:RABFF7830 stat:0008 t:00000000 d:FF r:7FFF     m:1D A258 A1A1A1 1C4E25 00FA
2014.01.19 20:34:43.282 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 20:37:04.182 0: HMLAN_Send:  HMLAN1 S:SAC01A0F7 stat:  00 t:00000000 d:01 r:AC01A0F7 m:1E A258 A1A1A1 1C4E25 00FA
2014.01.19 20:37:04.789 0: HMLAN_Parse: HMLAN1 R:RAC01A0F7 stat:0008 t:00000000 d:FF r:7FFF     m:1E A258 A1A1A1 1C4E25 00FA
2014.01.19 20:37:04.792 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 20:39:11.192 0: HMLAN_Send:  HMLAN1 S:SAC039119 stat:  00 t:00000000 d:01 r:AC039119 m:1F A258 A1A1A1 1C4E25 00FA
2014.01.19 20:39:11.799 0: HMLAN_Parse: HMLAN1 R:RAC039119 stat:0008 t:00000000 d:FF r:7FFF     m:1F A258 A1A1A1 1C4E25 00FA
2014.01.19 20:39:11.802 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 20:42:07.967 0: HMLAN_Send:  HMLAN1 S:SAC06439E stat:  00 t:00000000 d:01 r:AC06439E m:20 A258 A1A1A1 1C4E25 00FA
2014.01.19 20:42:08.291 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:2F47DF71 d:FF r:FFB2     m:20 8202 1C4E25 A1A1A1 0101C4004B
2014.01.19 20:42:09.147 0: HMLAN_Parse: HMLAN1 R:RAC06439E stat:0008 t:00000000 d:FF r:7FFF     m:20 A258 A1A1A1 1C4E25 00FA
2014.01.19 20:42:09.150 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25

an der stelle wo du es tust, müsstest du die verzögerung speichern und beim nächsten mal berücksichtigen, damit sie nicht unter den tisch fällt.

aber in jedem fall wird ein kostbarer umlauf verschenkt.

darum meine idee mit der gesplitteten funktion!

gruss frank

frank · 19 Januar 2014, 21:48:48

hallo martin,

wie schon vorausgesagt, kann die kommunikation nicht am leben gehalten werden, wenn der msgCounter ständig zurückgesetzt wird:

Code Auswählen

2014.01.19 21:14:01.038 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:15:59.960 0: HMLAN_Send:  HMLAN1 S:SAC254519 stat:  00 t:00000000 d:01 r:AC254519 m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:16:00.141 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:2F66E1F8 d:FF r:FFB2     m:02 8202 1C4E25 A1A1A1 0101C4004E
2014.01.19 21:16:00.571 0: HMLAN_Parse: HMLAN1 R:RAC254519 stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:16:00.573 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:16:21.915 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:18:27.863 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:18:27.877 3: VD-timing Critical ##### diff:923
2014.01.19 21:18:27.885 0: HMLAN_Send:  HMLAN1 S:SAC2786EE stat:  00 t:00000000 d:01 r:AC2786EE m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:18:28.494 0: HMLAN_Parse: HMLAN1 R:RAC2786EE stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:18:28.497 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:20:54.896 0: HMLAN_Send:  HMLAN1 S:+1C4E25,00,01,
2014.01.19 21:20:54.898 0: HMLAN_Send:  HMLAN1 S:SAC29C531 stat:  00 t:00000000 d:01 r:AC29C531 m:03 A258 A1A1A1 1C4E25 00FA
2014.01.19 21:20:55.505 0: HMLAN_Parse: HMLAN1 R:RAC29C531 stat:0008 t:00000000 d:FF r:7FFF     m:03 A258 A1A1A1 1C4E25 00FA
2014.01.19 21:20:55.508 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:21:23.637 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:23:07.408 0: HMLAN_Send:  HMLAN1 S:+1C4E25,00,01,
2014.01.19 21:23:07.411 0: HMLAN_Send:  HMLAN1 S:SAC2BCAD1 stat:  00 t:00000000 d:01 r:AC2BCAD1 m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:23:08.019 0: HMLAN_Parse: HMLAN1 R:RAC2BCAD1 stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:23:08.022 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:24:05.123 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:25:34.418 0: HMLAN_Send:  HMLAN1 S:SAC2E0913 stat:  00 t:00000000 d:01 r:AC2E0913 m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:25:35.026 0: HMLAN_Parse: HMLAN1 R:RAC2E0913 stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:25:35.030 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:26:32.336 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:28:01.679 3: VD-timing Critical ##### diff:266
2014.01.19 21:28:01.689 0: HMLAN_Send:  HMLAN1 S:SAC304859 stat:  00 t:00000000 d:01 r:AC304859 m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:28:02.368 0: HMLAN_Parse: HMLAN1 R:RAC304859 stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:28:02.372 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:28:44.635 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98
2014.01.19 21:30:28.696 0: HMLAN_Send:  HMLAN1 S:SAC328699 stat:  00 t:00000000 d:01 r:AC328699 m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:30:29.306 0: HMLAN_Parse: HMLAN1 R:RAC328699 stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 A1A1A1 1C4E25 03FA
2014.01.19 21:30:29.313 0: HMLAN_Parse: HMLAN1 no ACK from 1C4E25
2014.01.19 21:31:46.649 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98

nach dem letzten, (6.) fehlversuch ist der vd eingeschlafen.
mit durchlaufendem zähler hat er eben noch 1008ms verzögerung im 5. versuch geschafft. nun schafft er nicht mal 923ms. die zusätzlichen 266ms müssten eigentlich durch die prüfung herausgefiltert worden sein.

bitte die zähler durchlaufen lassen.

gruss frank

martinp876 · 20 Januar 2014, 11:33:10

Hallo Frank,

Zitatbitte die zähler durchlaufen lassen.

tun sie doch - oder?
nach einem restart leider nicht

warum kommt bei dir so oft 02?

frank · 20 Januar 2014, 12:01:11

moin martin,

bei jedem setzen von valvePos wird der zähler zurückgesetzt. beginnt immer bei m02. einmal kommt das neue set etwas später, dann zählt er bis m03. siehe letzter beitrag.

Code Auswählen

2014.01.19 21:14:01.038 2: CUL_HM set VentilControler.AZ_Btn1 valvePos 98

gruss frank

martinp876 · 20 Januar 2014, 12:20:05

danke - setzen hatte ich nicht kontrolliert...
Gruss Martin

frank · 20 Januar 2014, 14:45:09

hallo martin,

einen vd kann man auf 100% setzen:

Code Auswählen

2014-01-20_13:40:02 HMLAN1 RCV L:0B N:C1 F:A2 CMD:58 SRC:Thermostat.Kueche DST:Ventil.Kueche 00FF (ClimateEvent CMD:0x00 ValvePos:255) (,WAKEMEUP,BIDI,RPTEN)
2014-01-20_13:40:02 Ventil.Kueche set_100 %
2014-01-20_13:40:02 Ventil.Kueche ValveDesired: 100 %

wenn ich den virtuellen tc auf 100 setzen möchte, liefert mein notify folgendes:

Code Auswählen

2014.01.20 13:30:17.619 3: set_valvePos_notify return value: only number <= 100  or 'off' allowed

manuelles setzen über webfrontend möchte auch keine 100 setzen. obwohl die fehlermeldung doch "<=100" sagt.

ausserdem wird nach einem erfolgreichen absetzen von "set valvePos" im webfrontend die auswahlliste der set befehle seltsam neu gefüllt. ("leer",?,parameter,requires). erst ein sehr verzögertes neuladen der seite bringt die richtige auswahl zurück.

die readings scheinen sich auch nicht selbständig zu aktualisieren (detailansicht channel).

gruss frank

martinp876 · 20 Januar 2014, 15:26:44

Hi Frank,

gut getestet... das mit 100 wird erledigt. Version 4700

das mit den Kommandos und dem gelegentlichen nicht funktionieren des web-update ist mir unklar. Auch ob es etwas mit CUL_HM zu tun hat oder dem fhemweb...

Grus Maritn

frank · 20 Januar 2014, 17:02:51

hallo martin,

soweit gute arbeit. zähler läuft jetzt durch, 100% wird sauber verarbeitet.

an der zeitnahen eleminierung der verzögerungen arbeitest du noch?
oder ist dir mein beitrag vom 19 Januar 2014, 21:12:48 durch die lappen gegangen?

gruss frank

martinp876 · 20 Januar 2014, 20:01:46

Hi Frank,

ist mir durch die Lappen gegangen.

aber da ist eh noch ein fehler drin:
else {
$hash->{helper}{vd}{next} = $tn+$nextTimer;
}
$hash->{helper}{vd}{ackT} = $ackTime;
# $hash->{helper}{vd}{next} = $tn+$nextTimer;
$hash->{helper}{vd}{msgCnt} = $msgCnt;

die Zeile ist zu viel....

Also verstanden habe ich:
der VD - so er ein ACK schickt ist im trott und syncht sich auf ggf. kleine delays auf. Somit sollte die Berechnung für diesen Fall stimmen.
Sollte der VD einen step verpasst haben (warum auch immer) errechnet er den nächsten "meetingpoint" aus seinen daten - also versuchen wir dies auch und errechnen die Zeit vom alten timer vorwärts. Machen wir im Prinzip - eben nur die Zeile war nicht gelöscht.

Ist dies also unser Problem oder habe ich etwas übersehen/nicht verstanden?

Gruss Martin

frank · 20 Januar 2014, 21:33:49

hallo martin,

Zitatder VD - so er ein ACK schickt ist im trott und syncht sich auf ggf. kleine delays auf. Somit sollte die Berechnung für diesen Fall stimmen.

richtig!

ZitatSollte der VD einen step verpasst haben (warum auch immer) errechnet er den nächsten "meetingpoint" aus seinen daten - also versuchen wir dies auch und errechnen die Zeit vom alten timer vorwärts. Machen wir im Prinzip - eben nur die Zeile war nicht gelöscht.

richtig!

ZitatIst dies also unser Problem...

nein!

Zitatoder habe ich etwas übersehen/nicht verstanden?

ja!!!!

stell dir vor, die letzten kommunikationen waren alle ok. keine verzögerungen.
jetzt kommen wir in die funktion und prüfen. die prüfung ergibt alles ok, weil die letzte kommunikation gut war.
aber oh schreck. auf dem weg von der letzten kommunikation zu dieser aktuellen, die gleich am ende der funktion auf den weg gebracht wird, ist eine verzögerung von 7777ms entstanden.
die prüfung war ok, darum wird die aktuelle verzögerung nicht herausgerechnet, und geht in die nächste eventTime bestimmung mit ein. der zeitpunkt des nächsten funktionsdurchlauf.

##############################################

wir müssen in diesem funktionsdurchgang prüfen, ob die aktuell ermittelte verzögerung probleme gemacht hat oder nicht!

##############################################

Zitatdeine prüfung ist leider an der falschen stelle. sie muss hier her:

Code Auswählen Erweitern
Code: [Auswählen] CUL_HM_ProcessCmdStack($hash); ########## warten ########## ########## pruefung ########## InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);

an deiner stelle prüfst du zb m05 (msgNbr05), nimmst die verzögerung von m06 und veränderst die eventTime von m07.

gruss frank