TC emulieren

Begonnen von wkarl, 02 Januar 2014, 10:39:55

Vorheriges Thema - Nächstes Thema

martinp876

Zitatsomit habe ich nun den regler des tc vollkommen aus der regelung entfernen müssen.
hätte ich so erwartet. Wenn man das Ventil selbst steuern will muss man die Ventilstellung aus der Temperatur errechnen.

Zitatdas eigentliche ansteuern der vd läuft hingegen einwandfrei.
super.

Zitatgenerell gibt es eigentlich nur gelegentlich "einfache" (miss_1)
Zu beachten für User sind evtl Probleme bei Update und restart. Da kommt das timing ausser tritt - fängt sich nach einiger Zeit wieder. Das sollte in die Doku.

Zitateigentlich müsste es doch möglich sein, die kommunikation nach einem reset am leben zu halten?
hmmm - mal denken. Da gibt es mehrere Punkte
a) die Virtuellen Aktore starten nicht automatisch. Das müsste eingebaut werden, ist möglich
b) FHEM speichert attribute mit save und Readings bei updates u.ä. (müsste ich einmal genau nachsehen). Aktuell wird das timing in helper gespeichert - und das geht verloren.
b1) es wäre möglich die next timing in Readings ablegen und nach neustart ein Recovery probieren.

ich probiere einmal
Gruss Martin

p.s.
da jetzt humudity (virtHum) hinzugekommen ist habe ich den Code modifiziert. Gibt hoffentlich keine Probleme. Der Default für webCmd hat sich geändert, Gibt jetzt auch ein pull-down menu für valvePos, virtTemp und virtHum.


p.s.2 - das timing für ACK der virtuellen Aktoren habe ich auch angepasst (50ms)




martinp876

Hi,

im Anhang eine Version zum testen - es sollte das timing über einen shutdown restart aufrechterhalten.
Wenns klappt wird es eingecheckt

Gruss Martin

frank

hallo martin,

ich habe gerade die neue 10_cul.pm probiert, aber noch kein shutdown,restart, da irgendwas nicht so richtig funktioniert.

auf jeden fall kommt kein reading valveCtrl=ok mehr.

alles andere später.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

das sollte besser gehen (bezüglich 'ok')

frank

hallo martin,

beim wechsel von version_1 auf version_2 mit "shutdown & restart" haben 2/4 vd überlebt!

anschliessend habe ich ein reset der fritzbox durchgeführt ohne "shutdown & restart". immerhin 1/4 vd hat überlebt. der hat es sogar mit extremen daten geschafft:

2014.02.02 17:38:55.971 1: General VentilControler.Kueche_Btn1 ok:Ventil.Kueche:2014-02-02 17:38:46 - 2014-02-02 17:36:19
2014.02.02 17:43:30.351 1: Including fhem.cfg
2014.02.02 17:51:54.990 1: General VentilControler.Kueche_Btn1 ok:Ventil.Kueche:2014-02-02 17:51:45 - 2014-02-02 17:03:33


daraus lerne ich, dass eine aktuelle "fhem.save" überlebenswichtig ist! also gestöbert, folgendes entdeckt und sofort eingebaut. oder gibt es bereits etwas besseres?

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



fazit: geniale arbeit martin!
ps: ich werde gleich noch mal einen stromausfall simulieren. besten dank bis dahin.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

hallo martin,

während der ganzen überlebenstest der vd haben 2 vd die mitarbeit verweigert. ich habe immer nur auf eine funktionierende kommunikation geachtet und nicht bemerkt, das die 2 vd permanent auf 0% gesetzt waren.
die beiden haben die peer einträge verloren. wäre ja nicht weiter tragisch, wenn mann sie wieder setzen könnte. egal was ich mit dem peerchan auch anstelle, fhem sagt immer "peerChan requires parameter: <position> ". weder löschen des peers beim vtc, noch setzen im vd. vd resetet und neu gepairt. vtc entfernt und wieder definiert. immer nur "peerChan requires parameter: <position> ".
mir fällt nichts mehr ein.
es gibt auch keine hinweise zu dieser info. ist peerchan vielleicht irgendwie gesperrt, weil das set menue im vtc häufig (fast immer) falsche eingaben anzeigt?
irgendwann im laufe der letzten wochen war das schonmal. dann hat es, warum auch immer, irgendwann funktioniert.

++++++++++++++++++++++++++++++++++++++++++++++++++++++

gerade wollte ich ein list meiner devices machen und habe so aus langer weile zum1001 mal probiert. und dann klappt auf einmal alles, als wär das schon mmer so????????
also noch mal zum mit schreiben:

  • erst auf den browser tab vom forum
  • dann auf den tab vom webfrontend
  • dann den raum öffnen in dem der vtc ist
  • dann detailansicht parentdevice vom vtc
  • dann im eingabefeld den befehl ausführen
set VentilControler.Bad_Btn1 peerChan 0 Ventil.Bad single set actor
wenn man nun noch den remote anteil setzen will, reicht es nicht, den gleich im eingabefeld nach zu schieben. immer erst bei 1. anfangen!

ich glaub hier spukt es.
war auch gerade geisterstunde!

ps: nach stromausfall von fritzbox und hmlan hat 1/3 vd überlebt. (wahrscheinlich ohne peer)

gruss frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

hallo martin,

es gibt noch probleme.

1. der vtc sendet bei valvePos=100 das kommando "0x0300" für 0%. sehr unschön.

2014.02.03 12:36:39.035 2: CUL_HM set VentilControler.Bad_Btn1 valvePos 100
2014.02.03 12:38:14.112 0: HMLAN_Send:  HMLAN1 S:SF78AA220 stat:  00 t:00000000 d:01 r:F78AA220 m:04 A258 B3B3B3 193A9A 0300
2014.02.03 12:38:14.676 0: HMLAN_Parse: HMLAN1 R:RF78AA220 stat:0008 t:00000000 d:FF r:7FFF     m:04 A258 B3B3B3 193A9A 0300
2014.02.03 12:38:14.679 0: HMLAN_Parse: HMLAN1 no ACK from 193A9A
2014.02.03 12:38:14.685 0: HMLAN_Parse: HMLAN1 R:E193A9A   stat:0000 t:0357AF90 d:FF r:FFB6     m:04 8202 193A9A B3B3B3 0101BE2049

2014.02.03 12:39:29.829 2: CUL_HM set VentilControler.Bad_Btn1 valvePos 99
2014.02.03 12:40:23.627 0: HMLAN_Send:  HMLAN1 S:SF78C9C0C stat:  00 t:00000000 d:01 r:F78C9C0C m:05 A258 B3B3B3 193A9A 03FD
2014.02.03 12:40:24.192 0: HMLAN_Parse: HMLAN1 R:RF78C9C0C stat:0008 t:00000000 d:FF r:7FFF     m:05 A258 B3B3B3 193A9A 03FD
2014.02.03 12:40:24.195 0: HMLAN_Parse: HMLAN1 no ACK from 193A9A
2014.02.03 12:40:24.201 0: HMLAN_Parse: HMLAN1 R:E193A9A   stat:0000 t:0359A98E d:FF r:FFB6     m:05 8202 193A9A B3B3B3 0101001049


2. nach einem restart wird das reading valveCtrl falsch gesetzt.
zuerst "init"->ok, dann "ok"->falsch, dann "miss_1"->wieder ok. es wird "ok"gesetzt, obwohl keine antwort erhalten worden ist.

2014.02.02 23:04:25.356 0: Server shutdown
2014.02.02 23:04:25.389 4: CUL_send:  cul868X0 0     
2014.02.02 23:04:29.774 1: Including fhem.cfg
2014.02.02 23:04:44.308 1: Including ./log/fhem.save
2014.02.02 23:04:47.929 0: Server started with 353 defined entities (version $Id: fhem.pl 4709 2014-01-21 18:00:07Z rudolfkoenig $, os linux, user root, pid 2664)
2014.02.02 23:04:52.783 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: init
2014.02.02 23:04:52.997 1: ----- VD-STATUS ----- VentilControler.Bad_Btn1 valveCtrl: init
2014.02.02 23:04:53.216 1: ----- VD-STATUS ----- VentilControler.Kueche_Btn1 valveCtrl: init
2014.02.02 23:05:02.806 1: General VentilControler.SZ_Btn1 ok:Ventil.SZ:2014-02-02 21:59:25 -
2014.02.02 23:05:02.861 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: ok
2014.02.02 23:05:03.019 1: General VentilControler.Bad_Btn1 ok:Ventil.Bad:2014-02-02 23:02:32 -
2014.02.02 23:05:03.072 1: ----- VD-STATUS ----- VentilControler.Bad_Btn1 valveCtrl: ok
2014.02.02 23:05:03.239 1: General VentilControler.Kueche_Btn1 ok:Ventil.Kueche:2014-02-02 23:02:44 -
2014.02.02 23:05:03.292 1: ----- VD-STATUS ----- VentilControler.Kueche_Btn1 valveCtrl: ok
2014.02.02 23:06:10.713 1: General VentilControler.WZ_Btn1 ok:Ventil.WZ:2014-02-02 22:42:41 -
2014.02.02 23:06:10.767 1: ----- VD-STATUS ----- VentilControler.WZ_Btn1 valveCtrl: ok
2014.02.02 23:07:12.005 1: General VentilControler.Kueche_Btn1 miss_1:Ventil.Kueche:2014-02-02 23:02:44 - 2014-02-02 23:02:44
2014.02.02 23:07:12.061 1: ----- VD-STATUS ----- VentilControler.Kueche_Btn1 valveCtrl: miss_1
2014.02.02 23:07:41.537 1: General VentilControler.Bad_Btn1 miss_1:Ventil.Bad:2014-02-02 23:02:32 - 2014-02-02 23:02:32
2014.02.02 23:07:41.627 1: ----- VD-STATUS ----- VentilControler.Bad_Btn1 valveCtrl: miss_1
2014.02.02 23:07:58.338 1: General VentilControler.SZ_Btn1 miss_1:Ventil.SZ:2014-02-02 21:59:25 - 2014-02-02 21:59:25
2014.02.02 23:07:58.437 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: miss_1
2014.02.02 23:08:31.981 1: General VentilControler.WZ_Btn1 miss_1:Ventil.WZ: - 2014-02-02 22:42:41
2014.02.02 23:08:32.037 1: ----- VD-STATUS ----- VentilControler.WZ_Btn1 valveCtrl: miss_1


gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Hallo Frank,

Zitat"peerChan requires parameter: <position> ".
sollte nicht sein.
war evtl ein Bug, dass die Routine/perl nicht von 0 startet beim command-parsen.
Wenn es noch Probleme gibt bitte das genaue Kommando.

Ich habe evtl einen fix (hoffe ich).

Zum save habe ich mir folgende Pholosophie angeeignet:
- fhem.cfg wird (fast) ausschliesslich durch save beschreiben
=> save kann ich immer wieder machen, so oft ich will/muss
- mein eigenes UserCfg hänge ich per notify am ende an. Dies wird nie vom save überschrieben. ggf. würde es attribute von fhem.cfg überschreiben... da sollte man vorsicht walten lassen

woran ich arbeite ist ein handling der register/peer settings plus sereinnummer/FWversion... also "device-Config-Data".
Bislang gibt es in HMInfo ein
saveConfig: kumulatives speichern von Registern, peers, serialNr,...
loadConfig: gespeicherte Readings werden gelesen und - falls nicht gesetzt - in die Readings eingefügt.
purgeConfig: (neu, ab nächstem update) komprimiert das Kumulative config file. Somit kann man öfter bedenkenlos saveConfig ausführen.

Was noch fehlt ist ein automatisches auslösen des saveConfig, wenn entsprechende Daten geändert wurden.
In diesem Zug würde die FWversion, seriennummer und 2 andere von attribut nach readings wandern - wo sie hingehören.

Gruss Martin

p.s. 100% - wir sollten den Wert auf 99% beschränken - mehr kann er glaube ich eh nicht

frank

hallo martin,

Zitatp.s. 100% - wir sollten den Wert auf 99% beschränken - mehr kann er glaube ich eh nicht

nein.
die anzeige tc,vd ist zwar 0-99, aber der reale vd antwortet sowohl mit 0xc6 (198) als auch mit 0xc8 (200), wenn die anzeige 99 ist und der reale tc 0xff sendet. einmal ist operState onTarget einmal targetNotMet. sieht man sich den umrechnungsfaktor "*2" an, ergibt sich logischer weise 100% bei 0xc8.

also benötigen wir für reale und virtuelle devices:
1. tc->vd: 100%, 0xFF (255)
2. vd->tc: 100%, 0xC8 (200)

gruss frank

ps: über die "speichereien" muss ich erst meditieren!
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

hallo martin,

mit nun 5 vd, habe ich gerade einen neuen "überlebenstest" absolviert. war leider sehr enttäuschend. 0/5 vd haben überlebt.   :'(

jedenfalls kommt mir gerade der gedanke, das du da etwas übersehen haben könntest. ich finde das müsste vom prinzip sehr viel erfolgreicher verlaufen.

wenn ich das richtig analysiere, speicherst du "nur" den letzten erfolgreichen meetingpoint im reading ".next", um daraus einen neuen zeitpunkt zu errechnen. ich glaube das reicht nicht. du musst zusätzlich die msgNbr, die dem letzten erfolgreichen zeitpunkt zugrunde liegt, ebenfalls speichern und bei der weiteren berechnung mit einbeziehen.

jetzt bin ich mir sicher. ich habe mal aus meinem log was zusammengestellt:

2014.02.03 23:34:47.500 0: HMLAN_Send:  HMLAN1 S:SF9E3BA8D stat:  00 t:00000000 d:01 r:F9E3BA8D m:11 A258 B5B5B5 1C4E25 0300
2014.02.03 23:34:47.681 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:05B0DB4C d:FF r:FFC1     m:11 8102 1C4E25 B5B5B5 010100003F
2014.02.03 23:34:48.029 0: HMLAN_Parse: HMLAN1 R:RF9E3BA8D stat:0008 t:00000000 d:FF r:7FFF     m:11 A258 B5B5B5 1C4E25 0300

2014.02.03 23:35:08.813 0: Server shutdown

2014.02.03 23:40:08.912 1: ----- VD-STATUS ----- VentilControler.AZ.Nord_Btn1 valveCtrl: init
2014.02.03 23:40:08.944 0: HMLAN_Send:  HMLAN1 S:SF9E8A230 stat:  00 t:00000000 d:01 r:F9E8A230 m:02 A258 B5B5B5 1C4E25 0300
2014.02.03 23:40:09.558 0: HMLAN_Parse: HMLAN1 R:RF9E8A230 stat:0008 t:00000000 d:FF r:7FFF     m:02 A258 B5B5B5 1C4E25 0300

2014.02.03 23:41:09.174 1: General VentilControler.AZ.Nord_Btn1 ok:Ventil.AZ.Nord:2014-02-03 23:34:47 -


danach hatte der letzte gespeicherte meetingpoint die msgNbr 11, und das erste climateEvent nach dem shutdown hat die msgNbr 02. wir müssen genau wie beim durchlaufenlassen des zählers bei den positionsänderungen, die zähler vom letzen erfolgreichen meetingpunkt ausgehend, weiterlaufen lassen.
dann schaffen wir 100%!

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Hallo Frank
da kann ich garnichts vorteilhaftes gegensagen ;)
msgCnt wird entsprechend gerettet werden - lagere es jetzt ein

Gruss Martin

frank

#86
hallo martin,

ich habe dir mal etwas arbeit gestohlen.  :)


  elsif($cmd =~ m/^(valvePos|virtTemp|virtHum)$/) { ###########################
    my $valu = $a[2];
    my %lim = (valvePos =>{min=>0  ,max=>100,rd =>"valvePosTC" ,u =>" %"},
               virtTemp =>{min=>-20,max=>50 ,rd =>"temperature",u =>""  },
               virtHum  =>{min=>0  ,max=>99 ,rd =>"humidity"   ,u =>""  },);
    if ($valu eq "off"){
      if ($cmd eq "virtHum") {$hash->{helper}{vd}{vinH} = "";}
      else                   {$hash->{helper}{vd}{vin}  = "";}
      if ((!$hash->{helper}{vd}{vinH} || $hash->{helper}{vd}{vinH} eq "") &&
          (!$hash->{helper}{vd}{vin}  || $hash->{helper}{vd}{vin}  eq "") ){
        $state = "$cmd:stopped";
        RemoveInternalTimer("valvePos:$dst$chn");# remove responsePending timer
        RemoveInternalTimer("valveTmr:$dst$chn");# remove responsePending timer
        delete($hash->{helper}{virtTC});
      }
    }
    if ($hash->{helper}{virtTC} || $valu ne "off") {
      if ($valu ne "off"){
        return "level between $lim{$cmd}{min} and $lim{$cmd}{max} or 'off' allowed"
             if ($valu !~ m/^[+-]?\d+\.?\d?$/||
                 $valu > $lim{$cmd}{max}||$valu < $lim{$cmd}{min} );
        if ($cmd eq "virtHum") {$hash->{helper}{vd}{vinH} = $valu;}
        else                   {$hash->{helper}{vd}{vin}  = $valu;}
      }
      if ($cmd eq "valvePos"){
        my @pId = grep !/^$/,split(',',AttrVal($name,"peerIDs",""));
        return "virtual TC support one VD only. Correct number of peers"
          if (scalar @pId != 1);
        my $ph = CUL_HM_id2Hash($pId[0]);
        return "peerID $pId[0] is not assigned to a device " if (!$ph);
        $hash->{helper}{vd}{typ} = 1; #valvePos
        $hash->{helper}{vd}{id}  = $modules{CUL_HM}{defptr}{$pId[0]}
                                              ?$pId[0]
                                              :substr($pId[0],0,6);
        $hash->{helper}{vd}{cmd} = "A258$dst".substr($pId[0],0,6);
        CUL_HM_UpdtReadBulk($ph,1,
                         "state:set_$valu %",
                         "ValveDesired:$valu %");
        $hash->{helper}{vd}{val} = sprintf("%02X",($valu * 2.56)%256);
        $state = "ValveAdjust:$valu %";
      }
      else{#virtTemp || virtHum
        $hash->{helper}{vd}{typ} = 2; #virtTemp
        $hash->{helper}{vd}{cmd} = "8670$dst"."000000";
        my $t = $hash->{helper}{vd}{vin}?$hash->{helper}{vd}{vin}:0;
        $t *=10;
        $t -= 0x8000 if ($t < 0);
        $hash->{helper}{vd}{val} = sprintf("%04X", $t & 0x7fff);
        $hash->{helper}{vd}{val} .= sprintf("%02X", $hash->{helper}{vd}{vinH})
             if ($hash->{helper}{vd}{vinH} && $hash->{helper}{vd}{vinH} ne "");
      }
      $hash->{helper}{vd}{idh} = hex(substr($dst,2,2))*20077;
      $hash->{helper}{vd}{idl} = hex(substr($dst,4,2))*256;
      $hash->{helper}{vd}{msgCnt} = ReadingsVal($name,".msgCnt",0)
if (!defined $hash->{helper}{vd}{msgCnt});
      if (!$hash->{helper}{virtTC}){
my $pn = CUL_HM_id2Name($hash->{helper}{vd}{id});
        $hash->{helper}{vd}{ackT} = ReadingsTimestamp($pn, "ValvePosition", "")
if (!defined $hash->{helper}{vd}{ackT});

        $hash->{helper}{vd}{miss} = 0  if (!defined$hash->{helper}{vd}{miss});
        $hash->{helper}{virtTC}   = ($cmd eq "valvePos")?"03":"00";
        CUL_HM_UpdtReadSingle($hash,"valveCtrl","init",1)if ($cmd eq "valvePos");
        $hash->{helper}{vd}{next} = ReadingsVal($name,".next",gettimeofday())
if (!defined $hash->{helper}{vd}{next});
        CUL_HM_valvePosUpdt("valvePos:$dst$chn");
      }
      $hash->{helper}{virtTC} = ($cmd eq "valvePos")?"03":"00";
    }
    CUL_HM_UpdtReadSingle($hash,$lim{$cmd}{rd},$valu.$lim{$cmd}{u},1);
  }

sub CUL_HM_valvePosUpdt(@) {#update valve position periodically to please valve
  my($in ) = @_;
  my(undef,$vId) = split(':',$in);
  my $hash = CUL_HM_id2Hash($vId);
  my $name = $hash->{NAME};
  my $msgCnt = $hash->{helper}{vd}{msgCnt};
my ($idl,$lo,$hi,$nextTimer);
  $hash->{helper}{vd}{nextF} = $hash->{helper}{vd}{next};
  my $tn = gettimeofday();
do {
$msgCnt = ($msgCnt + 1)%255;
# int32_t result = (((_address << 8) | messageCounter) * 1103515245 + 12345) >> 16;
#                          4e6d = 20077                        12996205 = C64E6D
# return (result & 0xFF) + 480;
$idl = $hash->{helper}{vd}{idl}+$msgCnt;
$lo = int(($idl*0x4e6d +12345)/0x10000)&0xff;
$hi = ($hash->{helper}{vd}{idh}+$idl*198)&0xff;
$nextTimer = (($lo+$hi)&0xff)/4 + 120;#original - instable
$hash->{helper}{vd}{nextF} += $nextTimer;
} until ($hash->{helper}{vd}{nextF} > $tn);
  $hash->{helper}{vd}{nextM} = $tn+$nextTimer;
  $hash->{helper}{vd}{msgCnt} = $msgCnt;
  if ($hash->{helper}{vd}{cmd}){
    if ($hash->{helper}{vd}{typ} == 1){
      CUL_HM_PushCmdStack($hash,sprintf("%02X%s%s%s"
                                        ,$msgCnt
                                        ,$hash->{helper}{vd}{cmd}
                                        ,$hash->{helper}{virtTC}
                                        ,$hash->{helper}{vd}{val}));
    }
    else{
      CUL_HM_PushCmdStack($hash,sprintf("%02X%s%s"
                                        ,$msgCnt
                                        ,$hash->{helper}{vd}{cmd}
                                        ,$hash->{helper}{vd}{val}));
    }
  }
  else{
    delete $hash->{helper}{virtTC};
    CUL_HM_UpdtReadSingle($hash,"state","stopped",1);
    return;# terminate processing
  }
  $hash->{helper}{virtTC} = "00";
  CUL_HM_ProcessCmdStack($hash);
  InternalTimer($tn+10,"CUL_HM_valvePosTmr","valveTmr:$vId",0);
}
sub CUL_HM_valvePosTmr(@) {#calc next vd wakeup
  my($in ) = @_;
  my(undef,$vId) = split(':',$in);
  my $hash = CUL_HM_id2Hash($vId);
  my $name = $hash->{NAME};
  if ($hash->{helper}{vd}{typ} == 1){
    my $pn = CUL_HM_id2Name($hash->{helper}{vd}{id});
    my $ackTime = ReadingsTimestamp($pn, "ValvePosition", "");
    my $vc;
    if (!$ackTime || $ackTime eq $hash->{helper}{vd}{ackT} ){
$hash->{helper}{vd}{next} = $hash->{helper}{vd}{nextF};
      $vc = (++$hash->{helper}{vd}{miss} > 5)
                                          ?"lost"
                                          :"miss_".$hash->{helper}{vd}{miss};
      Log3 $name,5,"CUL_HM $name virtualTC use fail-timer";
    }
    else{
CUL_HM_UpdtReadBulk($hash,0,".next:".$hash->{helper}{vd}{next}
,".msgCnt:".($hash->{helper}{vd}{msgCnt}-1));
$hash->{helper}{vd}{next} = $hash->{helper}{vd}{nextM};
      $vc = "ok";
      $hash->{helper}{vd}{miss} = 0;
    }
    CUL_HM_UpdtReadSingle($hash,"valveCtrl",$vc,1)
          if(ReadingsVal($name,"valveCtrl","") ne $vc);
    $hash->{helper}{vd}{ackT} = $ackTime;
  }
  InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
}


damit geht:

shutdown & restart:                                      5/5 -> 100%
fritzbox reset (ohne shutdown):                    5/5 -> 100%
5 min stromausfall (fritzbox, hmlan):             5/5 -> 100%

hier der log vom stromausfall
2014.02.05 00:35:43.249 1: General VentilControler.AZ.Nord_Btn1 ok:Ventil.AZ.Nord:2014-02-05 00:35:33 - 2014-02-05 00:33:04

######################### 7mmin 26sec offline ###############################################

2014.02.05 00:43:09.406 1: Including fhem.cfg
2014.02.05 00:43:13.896 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.02.05 00:43:13.958 1: HMLAN_Parse: HMLAN1 new condition init
2014.02.05 00:43:24.754 1: Including ./log/fhem.save
2014.02.05 00:43:28.120 1: ----- VD-STATUS ----- VentilControler.Kueche_Btn1 valveCtrl: init
2014.02.05 00:43:29.392 0: Server started with 356 defined entities (version $Id: fhem.pl 4709 2014-01-21 18:00:07Z rudolfkoenig $, os linux, user root, pid 1743)
2014.02.05 00:43:32.105 1: HMLAN_Parse: HMLAN1 new condition ok
2014.02.05 00:43:34.007 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: init
2014.02.05 00:43:34.203 1: ----- VD-STATUS ----- VentilControler.Bad_Btn1 valveCtrl: init
2014.02.05 00:43:34.489 1: ----- VD-STATUS ----- VentilControler.WZ_Btn1 valveCtrl: init
2014.02.05 00:43:34.750 1: ----- VD-STATUS ----- VentilControler.AZ.Nord_Btn1 valveCtrl: init
2014.02.05 00:43:38.215 1: ----- VD-STATUS ----- VentilControler.Kueche_Btn1 valveCtrl: miss_1
2014.02.05 00:43:44.078 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: miss_1
2014.02.05 00:43:44.276 1: ----- VD-STATUS ----- VentilControler.Bad_Btn1 valveCtrl: miss_1
2014.02.05 00:43:44.560 1: ----- VD-STATUS ----- VentilControler.WZ_Btn1 valveCtrl: miss_1
2014.02.05 00:43:44.821 1: ----- VD-STATUS ----- VentilControler.AZ.Nord_Btn1 valveCtrl: miss_1
2014.02.05 00:44:21.664 1: ----- VD-STATUS ----- VentilControler.Kueche_Btn1 valveCtrl: ok
2014.02.05 00:44:32.189 1: ----- VD-STATUS ----- VentilControler.WZ_Btn1 valveCtrl: ok
2014.02.05 00:44:42.151 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: miss_2
2014.02.05 00:44:42.261 1: ----- VD-STATUS ----- VentilControler.Bad_Btn1 valveCtrl: ok
2014.02.05 00:45:23.555 1: ----- VD-STATUS ----- VentilControler.AZ.Nord_Btn1 valveCtrl: ok
2014.02.05 00:47:22.382 1: ----- VD-STATUS ----- VentilControler.SZ_Btn1 valveCtrl: ok


gruss frank

ps: du machst bitte noch den 100%-bug von beitrag « Antwort #83 am: 03 Februar 2014, 22:35:46 »

pps: damit geht jetzt sogar das set-pulldown-menue beim vtc:chn01!

ppps: ich glaube es gibt ein problem,wenn der msg-zähler "überläuft"! wäre es möglich, dass es msgNbr=00 im durchlauf nicht gibt?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

danke - habe es sinngemäß übernommen.
habe die Varibalen aus Readings genommen - hast du angst vor der Performance, weil du sie nach Helper kopierst?
Die unitl-loop ist gut - fängt noch einmal ein paar, die knapp am trigger restarten.

Max level ist 99% - 100 gibt es nicht... ist so

ja, pull-down geht seit ein paar Versionen - auch beim Thermostat.

Gruss Martin

frank

hallo martin,

Zitathabe die Varibalen aus Readings genommen - hast du angst vor der Performance, weil du sie nach Helper kopierst?

so wie du die readings "missbrauchst", geht es nicht. du hast sie in der 1. funktion gesetzt, um sie in der 2. funktion zu benutzen. diese daten sind aber keine korrekten meetingpoint-daten. bei systemabsturz wird dann auf diese "falschen" daten zugegriffen.

die readings dürfen nur gesetzt werden, wenn eine prüfung die daten bestätigt hat (timerfunktion, prüfung, else-teil). wenn du die readings nutzt, musst du sicherstellen, dass zu jeder zeit gültige meetingpoint-daten zur rettung der vd enthalten sind.

du kannst das verhalten der readings sehr schön in der detailansicht von vtc:chn01 bei den timestamps beobachten. 1. müssen die timestamps von .msgCtr und .next immer gleich sein. beide readings müssen immer zusammen passen. und 2. immer mit einem neuen valveCtrl=ok timestamp identisch sein.

desweiteren (funktion valvePosUpdt) wird die variable $hash->{helper}{vd}{nextF} erst erfolgreich in der do schleife gesetz, um sie ein paar zeilen später wieder zu überschreiben.

zusätzlich hat mir gerade ein "set clear readings" beim vtc das system lahmgelegt. selbst ein reset der fritzbox hilft nicht mehr. im logfile tauchen nur noch alle 10 min daten auf. das webfrontend kommt nicht mehr durch. ich muss leider mit meiner cul_hm version vorlieb nehmen.  ;)

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Zitatso wie du die readings "missbrauchst", geht es nicht. du hast sie in der 1. funktion gesetzt, um sie in der 2. funktion zu benutzen. diese daten sind aber keine korrekten meetingpoint-daten. bei systemabsturz wird dann auf diese "falschen" daten zugegriffen.
der errechnete Wert aus CUL_HM_valvePosTmr sollte immer gültig sein und somit nach readings geschrieben werden können. Wenn FHEM jetzt damit arbeitet MUSS man damit weiter arbeiten können - auch nach reboot.

Zitatdie readings dürfen nur gesetzt werden, wenn eine prüfung die daten bestätigt hat (timerfunktion, prüfung, else-teil).
warum? Ohne restart würden wir mit dem then Zweig weiter arbeiten - also siehe oben.
Nach dem reset errechnest du es alles in der Until schleife noch einmal... sollte hoffentlich exakt die gleichen Werte ergeben. ok - du sparst das setzen des Readings (normalfall) und errechnest es ggf (Ausnahmefall). Ist also schneller. Die until schleife wird dafür immer bearbeitet - das kostet wiederum Performance...

Zitatwenn du die readings nutzt, musst du sicherstellen, dass zu jeder zeit gültige meetingpoint-daten zur rettung der vd enthalten sind.
klar - deshalb immer mit readings arbeiten. Der Satz muss selbstverständlich komplett sein.

Fraglich, warum du
      CUL_HM_UpdtReadBulk($hash,0,".next:".$hash->{helper}{vd}{next}
                                 ,".msgCnt:".($hash->{helper}{vd}{msgCnt}-1));
      $hash->{helper}{vd}{next} = $hash->{helper}{vd}{nextM};

hier einen Wertesatz vorher ablegst und nicht den, der als nächstes erwartet würde (kein -1 sowie den errechneten Wert nextM in die Readings). Klar - müsste dann auch so in der Berechnung bei Neustart berüchsichtigt werden. Kein Problem sondern ein anderes Herangehen.

Zitatdesweiteren (funktion valvePosUpdt) ... wieder zu überschreiben.
ok, ist klar - copyfehler - meine schuld.

Zitatzusätzlich hat mir gerade ein "set clear readings" beim vtc das system lahmgelegt.
ok - das ist ein Argument zur doppelten Datenhaltung - readings nur als faultback...
Wäre ohne den obigen copy-fehler wohl nicht in dem Ausmaß passiert.

Habe deine Version eingecheckt, zumindest ist der operationale Betrieb somit vom clear Readings  nicht betroffen (wenn danach nicht gleich ein reboot kommt)

Danke
Martin