TC emulieren

[martinp876]

Hi Frank,

zum Loggen sollte man einen log einbauen - das macht meht sinn. Ein Reading sind dafür nicht gedacht.
miss ist dann ein Problem in sich. Es gibt dann ausgelassene messages die durch nicht-antworten(fehler) oder durch auslassen (absicht) erzeugt werden. Mein Vorschlag ist

- miss zaehlt alle ausslassungen
- das Reading wird nur gesetzt, wenn es ein Fehler ist.

Klingt zufriedenstellend?

Bin noch am Testen - wird evtl morgen - muss jetzt gehen

Gruss Martin

[frank]

hallo martin,

- miss zaehlt alle ausslassungen
- das Reading wird nur gesetzt, wenn es ein Fehler ist.

Klingt zufriedenstellend?

sehr gut!

zum Loggen sollte man einen log einbauen - das macht meht sinn.

du meinst ein eintrag in fhem.log? das muss, meine ich, nicht sein, kann aber nicht schaden. doch hier geht mir viel verloren, wenn ich versuche mache, und mit zb global verbose 1 alles versuchsunrelevante abgeschaltet ist.

ich möchte ja auch plotten können, wie unten im bild zu sehen ist. hier müsste dann der reduce-modus mit anzuzeigen sein. im augenblick kann man durch die vorhandenen idle zustände erkennen, wann der skip-modus anfägt (nach dem ersten init kurz nach 2.00). jetzt sollen die idle zustände wegfallen. würde man dann zwischen 3.30 und 11.00 (7,5 std ohne fehler) den reduce-modus wechseln, kann man nicht erkennen, wann das geschehen ist. nur die art der fehler lässt erkennen, welcher modus eingeschaltet war. denn ein miss2-fehler ohne miss1, kann nur im skip-modus vorkommen (fehler nach idle).
wenn mein ziel erreicht ist, sieht man gar keine fehler mehr, dann wirds richtig schwierig. 

wie wäre es, wenn man nach reduce-modus wechsel immer bei init einsteigt? dann könnte man den modus durch init0-init9 erkennbar machen. oder mit ready verknüpfen.

3) skip nur, wenn der wert nicht geaendert wurde (oder anders herum: force send if changed)

das ist gut. könnte man mit valveCtrl=force kennzeichnen. um zu erkennen, ob überhaupt noch reduziert wird. wer hohe reduzierung reduce9 haben möchte, muss das ja erkennen können, um seinen regler entsprechend anzupassen.
schaltbar wäre noch besser. zb mit reduce verknüpfen. einige könnte man ja opfern. eine hälfte reduce ohne force, die andere hälfte reduce mit force. im force modus braucht man ja wohl auch nicht so hohe reduce werte.

da bin ich mal gespannt, was der weihnachtsmann so bringt. 

gruss frank

[martinp876]

Hi Frank,

4931 ist übertragen.

Generell ist Readings nicht dazu gedacht, zu debuggen. Wir werden die SW so stabil machen, dass wenn man reduces:4 einstellt 4 transmist ausgelassen werden - das muss verlaesslich sein und nicht ueber Readings geprüft werden. Logs könnte man dazu einbauen....
Readings sind für Änderungen an des Devices, die sporadisch, und nicht vorhersehbar seid.

Prüfe einmal ...
Gruss Martin

[frank]

hallo martin,

Prüfe einmal ...

wenn die alte einstellung msgReduce ohne zahl auch gehen sollte, dann sieht es schlecht aus. der zustand ready nach init wird nicht erreicht. nur miss1 bis lost.

gruss frank

[martinp876]

bin noch einmal am nachtesten, kann es aber nicht sehen.
Was machst du?

Du hast ein virt device mit einem virt channel der mit einem VD gepeert ist.
Dem virtChannel gibtst du das Attribut
attr vrtCh param msgReduce
oder
attr vrtCh param msgReduce:1
oder
attr vrtCh param msgReduce:5

sollte bei list vrtCh zu sehen sein:
vrtCh->helper->vd->msgRed 1 oder 5

So weit ok?
der Rest läuft bei mir wir prospektiert.

testest du beretis sonderfälle? Restart oder so?

Gruss Martin

[frank]

hallo martin,

Du hast ein virt device mit einem virt channel der mit einem VD gepeert ist.
Dem virtChannel gibtst du das Attribut
attr vrtCh param msgReduce

das war meine konfiguration bevor ich v4939 mit shtutdown/restart gestartet habe.

alle vtc sind nach restart mit valveCtr= init,miss1,...,miss5,lost eingeschlafen. (bisher gab es immer ready nach init)

nach einer stunde sind die vd von selber aufgewacht, und seitdem können sie am leben gehalten werden. bei 4 vtc habe ich noch garnichts verändert. bei einem hatte ich versucht über das neue "msgReduce:1" das sterben zu verhindern. hatte nicht genutzt.

augenblickliches fazit:
"msgReduce" und "msgReduce:1" kann man verwenden.
das sterben betrift wohl nur die rettungsroutine nach reset.

gruss frank

[frank]

hallo martin,

keine reduzierung,weder mit msgReduce:2, noch mit msgReduce:3. hmlan sendet alle 2-3 minuten.
gibt es bereits force send?

list vom vtc mit reduce2:

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   CHANGED   
   DEF        B3B3B301
   NAME       VentilControler.Bad_Btn1
   NR         467
   STATE      Vsoll:21 %, Status:ValveAdjust:21 %, Kommunikation:miss_1
   TYPE       CUL_HM
   chanNo     01
   device     VentilControler.Bad
   peerList   Ventil.Bad,
   Readings:
     2014-02-15 17:27:44   .msgCnt         71
     2014-02-15 17:27:44   .next           1392481654.13823
     2014-02-15 17:31:52   state           ValveAdjust:21 %
     2014-02-15 17:30:53   valveCtrl       miss_1
     2014-02-15 17:30:53   valveCtrlRam    miss_1
     2014-02-15 17:31:52   valvePosTC      21 %
   Helper:
     fkt        vdCtrl
     virtTC     03
     Role:
       chn        1
       vrt        1
     Vd:
       ackT       2014-02-15 17:27:34
       cmd        A258B3B3B3193A9A
       id         193A9A
       idh        3593783
       idl        45824
       miss       1
       msgCnt     73
       msgRed     2
       msgSent    1
       next       1392481985.15051
       nextF      1392481985.15051
       nextM      1392482001.91477
       typ        1
       val        35
       vin        21
Attributes:
   alias      30. Controler
   event-on-change-reading valveCtrl
   expert     1_on
   group      Heizung.Bad
   model      virtual_1
   param      msgReduce:2
   peerIDs    193A9A01,
   room       98_Ventile
   stateFormat Vsoll:valvePosTC, Status:state, Kommunikation:valveCtrl
   webCmd     press short:press long

gruss frank

[martinp876]

Frank,

setzt du den Wert ständig? Wie angekündigt wird ein geaenderter wert immer übertragen.
In dem List sehe ich dass der Wert gerade frisch gesetzt wurde.

Das auslassen funktioniert bei mir zu 100%. Und wenn ich einen Wert vorgebe (also set  valvePos auslöse) wird beim nächsten mal gesendet - und dann erst der darauffolgende ausgelassen

Gruss Martin

[frank]

hallo martin,

der pid20-regler setzt wahrscheilich nach jeder berechnung (60sec) einen wert, die werte ändern sich aber nicht ständig.

nach deiner beschreibung sendet er also nicht nur nach änderung sondern bei jedem setzen. dann wird natürlich nie geändert.

gruss frank

[martinp876]

Hi Frank,

so ist es (aktuell).
Mir gefällt es so - damit kann ich einen "Force" trigger einfach auslösen.
Es wäre hilfreich, den PID  nur senden zu lassen, wenn er auch etwas geändert hat. Wenn er alle 60sec sendet ist dies eh übertrieben, da der VTC 2,5 mal öfter aufgerufen wird, als er überhaupt kann.
Kannst du ihn auf "event-on-change-reading" setzen, damit er handlicher wird? Alles andere klingt nicht sinnvoll für mich.

Klar kann man es auch im VTC ändern/blockieren. Ist aber nicht sauber, da es viel früher geblockt werden sollte
Gruss Martin

[frank]

hallo martin,

ich konnte dem regler erfolgreich mitteilen, das er hauptsächlich nur bei änderungen den set-befehl sendet. nun klappt es auch bei mir. es ist natürlich kaum mehr zu überblicken, was da genau passiert.

wenn ich von hmlan msgloadest ausgehe, sollte es sehr gut funktionieren. vorher hatte ich bei skip ohne force, im langen mittel um 10.5%. jetzt mit der einstellung msgreduce:2 vielleicht 11%. leider versauen heute viele disconnects eine stabile messkurve. da in der theorie durch die zusätzlichen force meldungen mehr traffic zu erwarten ist, sollte die tendenz im vergleich passen.

ich habe jetz mal alle 5 vtc auf reduce3 gestellt und werde morgen sehen was passiert.

eine unerklärliche auffälligkeit muss ich noch erwähnen. bei einem vtc gab es miss3 fehler, obwohl reduce2 eingestellt war (wahrscheinlich). nach meinem verständnis sollte das unmöglich sein. oder? also ein sprung von ok auf miss3. 

hast du mal ein reset versuch getestet?

gruss frank

[martinp876]

Hi Frank,

ein miss3 ist möglich, wenn die antwort nach Miss2 nicht gekommen ist.

Zu deinen Überwachungen - hier muss man sich das Ziel einer automation Anlage klar machen. Erste einmal sollten ereignisse des Environments angezeigt werden - das will man überwachen, nicht die Anlage. Die Anlage will man kontrollieren.
In der Entwicklungsphase will man debuggen - und das ist der Level, den du suchst.
Debuggen ist temporär - es sollte irgendwann stabil sein, dann läuft die Kiste Debug Info muss dann weg sein, nur noch Alarme.
Zum debuggen gibt es jede Menge Möglichkeiten und Indikatoren - message statistic auf verschiedenen leveln - wenns sein muss die rohmessages mitschreiben, oder hmProtocolEvents... Alternativ kann man logs einbauen. Das sollte reichen. Readings sind defnitiv nicht debug-level für System-interna.

Gruss Martin

[frank]

hallo martin,

ein miss3 ist möglich, wenn die antwort nach Miss2 nicht gekommen ist.

nein, denn:

reduce2 => maximal eine message wird ausgelassen. (0 wenn force, sonst 1)
also:
auslassen erzeugt miss1_unvisible (soll nicht angezeigt werden).
fehler nach auslassen erzeugt miss2 (soll angezeigt werden).
fehler nach miss2 erzeugt miss3 (soll angezeigt werden).

wie kommt dann ein miss3 ohne vorangegangenen miss2 zustande? ein miss3 ohne vorangegangenen miss2, bedeutet nach meiner logik: 2 mal auslassen, dann fehler. sollte bei reduce2 nicht möglich sein! siehe grafik.

gleiches problem bei reduce3 => maximal 2 messages werden ausgelassen. (0 oder 1 wenn force, sonst 2)
ich erhalte aber unter anderem miss4 ohne vorangegangenen miss3.

----------------------------------------------------------------------------------------------

Readings sind für Änderungen an des Devices, die sporadisch, und nicht vorhersehbar seid.

nach dieser philosophie, ist aus sicht eines virtuellen tc, der im modus reduce läuft, ein force unvorhersehbar und sporadisch.

gruss frank

[frank]

hallo martin,

ich habe eine dynamische einstellung vorbereitet - muss ich noch testen

Code Auswählen Erweitern

attr vtc param msgReduce:5

sendet dann erst den 5.

mit reduce3 sieht mein log so aus. anhand der msgnummer ist zu erkennen, dass er aber 3 mal auslässt, und nicht 2 mal. dann ist miss4 natürlich richtig.

ist nun die beschreibung des features falsch oder die implementierung?

Code Auswählen Erweitern

2014.02.16 08:41:05.297 0: HMLAN_Send:  HMLAN1 S:S39A430D3 stat:  00 t:00000000 d:01 r:39A430D3 m:B1 A258 B5B5B5 1C4E25 0017
2014.02.16 08:41:05.477 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0C27B941 d:FF r:FFB2     m:B1 8202 1C4E25 B5B5B5 010112004D
2014.02.16 08:41:05.858 0: HMLAN_Parse: HMLAN1 R:R39A430D3 stat:0008 t:00000000 d:FF r:7FFF     m:B1 A258 B5B5B5 1C4E25 0017

2014.02.16 08:51:22.813 0: HMLAN_Send:  HMLAN1 S:S39AD9CFB stat:  00 t:00000000 d:01 r:39AD9CFB m:B5 A258 B5B5B5 1C4E25 0321
2014.02.16 08:51:22.995 0: HMLAN_Parse: HMLAN1 R:E1C4E25   stat:0000 t:0C3125C0 d:FF r:FFB3     m:B5 8202 1C4E25 B5B5B5 010112104D
2014.02.16 08:51:23.375 0: HMLAN_Parse: HMLAN1 R:R39AD9CFB stat:0008 t:00000000 d:FF r:7FFF     m:B5 A258 B5B5B5 1C4E25 0321

2014.02.16 09:01:03.302 0: HMLAN_Send:  HMLAN1 S:S39B67886 stat:  00 t:00000000 d:01 r:39B67886 m:B9 A258 B5B5B5 1C4E25 0021
2014.02.16 09:01:03.910 0: HMLAN_Parse: HMLAN1 R:R39B67886 stat:0008 t:00000000 d:FF r:7FFF     m:B9 A258 B5B5B5 1C4E25 0021
2014.02.16 09:01:13.366 1: ----- VD-STATUS ----- VentilControler.AZ.Nord_Btn1 valveCtrl: miss_4

gruss frank

[martinp876]

mit reduce3 sieht mein log so aus. anhand der msgnummer ist zu erkennen, dass er aber 3 mal auslässt,

hört sich gut an für mich.
reduce 0: kein auslassen
reduce 1: einmal auslassen
....

es ist die Beschreibung. Der Name des Parameter impliziert das aktuelle Verhalten - meine ich

Gruss Martin