CUL mit timestamp option

[martinp876]

Hallo Rudi,
Ansgar hat eine FW vorbereitet mit der man (endliche) timestamps von der CUL erhalten kann. Da mit lässt sich das Timing verbessern - er kommen deutlich weniger übertragungsfehlern.
Im Anhang ist die passende Version 00_CUL, mit der das feature genutzt werden kann.
Die Timestamp-option wird eingesschaltet, wenn eine CUL_V3 mit FW Größer 1.59 erkannt wird.

Kannst du die Version bitte einchecken?
Ansgar bracht noch hilfe, wie er die CUL_FW angeben soll. Wo muss diese hin?

Gruss Martin

[rudolfkoenig]

Ich habe folgende Probleme mit dem Patch:
- es ist wohl nicht nur ein timing-patch, da sind auch andere Kleinigkeiten mit drin, ueber deren Zweck ich nur mutmassen kann (z.Bsp. CUL_RemoveHMPair Parameter Umbenennung)
- ich finde die Loesung mit HardwareName abfragen schlecht: SCC/COC/CUL_V4/etc Besitzer haben das Nachsehen.
- das spezielle Formatieren der Nachricht im HM Fall stoert mich zunehmend: z.Bsp. reichen auch rfmode=Homematic SCC's die Daten der draufgestecktem SCCs (die dann in SlowRF oder MAX-Mode sind) weiter, diese Nachrichten werden in 00_CUL.pm kaputtformatiert. Mir ist wichtig Nachrichten in CUL nicht umzuformatieren, sondern so anzuzeigen, wie sie empfangen wurden. Fuers Interpretieren ist das Homematic Modul zustaendig, und nicht das CUL Modul.
- aus dem gleichen Grund ist eine direkte Abfrage eines Nachrichtes abhaengig vom rfmode falsch ($flg eq "FF"). HM Nachrichten fangen mit A an, das sollte man pruefen.
- die Kommentare in CUL_dlytime sind irrefuehrend (es gibt kein drft, etc), und gettimeofday (Systemcall) sollte man auch nur einmal aufrufen.

Ansgar bracht noch hilfe, wie er die CUL_FW angeben soll. Wo muss diese hin?

Ich verstehe diese Frage nicht.

[martinp876]

- es ist wohl nicht nur ein timing-patch, da sind auch andere Kleinigkeiten mit drin, ueber deren Zweck ich nur mutmassen kann (z.Bsp. CUL_RemoveHMPair Parameter Umbenennung)

Verstehe das nicht.
CUL_RemoveHMPair wird vom Timer gestartet - als Indikator wird - wie so oft "hash" genutzt. Damit kann man nur einen Timer für eine Entiy unterscheiden - insbesondere wenn man löschen will. Halte ich ich also generell für fragwürdig, zumindest für wenig Praktikabel. An dieser Stelle habe ich
- den Timer genau Spezifiziert (Namen und Zweck)
- den Aufruf lesbar gemacht
- das Löschen auch des hmPairSerial eingebaut - falls es schief gegangen ist.
=> generell biete ich an, das pairen in die vccu von CUL_HM zu verscheiben

- ich finde die Loesung mit HardwareName abfragen schlecht: SCC/COC/CUL_V4/etc Besitzer haben das Nachsehen.

warum? WAs meinst du im Detail? Wenn du die Abfrage "vh" meinst - die ist notwendig, weil es Pflicht für das System ist, zu wissen welche HW vorliegt. Sollte das IO die Frage nicht beantworten können sonderfunktionen ab bestimmten FW-ständen nicht eingeschaltet werden. Das geht eben nicht und  MUSS unterbunden werden.
Welches Nachsehen meinst du?

- das spezielle Formatieren der Nachricht im HM Fall stoert mich zunehmend:

mich nicht

z.Bsp. reichen auch rfmode=Homematic SCC's die Daten der draufgestecktem SCCs (die dann in SlowRF oder MAX-Mode sind) weiter, diese Nachrichten werden in 00_CUL.pm kaputtformatiert. Mir ist wichtig Nachrichten in CUL nicht umzuformatieren, sondern so anzuzeigen, wie sie empfangen wurden. Fuers Interpretieren ist das Homematic Modul zustaendig, und nicht das CUL Modul

.
das sehe ich nicht so. Ich will sehen, was im IO passiert - das macht man im IO. Insbesondere Delays, die im IO berechnet werden MÜSSEN!. Dass man die Nachrichten mit ein paar blanks versieht macht das ganze nur lesbar.
Gerne kann man überlegen, nicht-HMmodes unformatiert zu lassen. Woran erkenne ich das?

- aus dem gleichen Grund ist eine direkte Abfrage eines Nachrichtes abhaengig vom rfmode falsch ($flg eq "FF"). HM Nachrichten fangen mit A an, das sollte man pruefen.

ich mache beides - und muss beides machen.
Gerne kann der Log-Aufruf nach der IF $fn Abfrage gemacht werden, dann kann ich alles in einem Zug machen - wäre mit eh lieber

- die Kommentare in CUL_dlytime sind irrefuehrend (es gibt kein drft, etc), und gettimeofday (Systemcall) sollte man auch nur einmal aufrufen.

Kann mann - dann wird es eben immer aufgerufen. Jetzt ist es fallabhängig und kommt evtl garnicht.
bei drft hast du recht - gibt es (noch) nicht. Würde für eine Präzisere Analyse benötigt - die es aber erst geben kann, wenn die CUL gepingt wird. Damit kann man dann timing-drifts des CUL oszilators egalisieren. Ausserdem könnte man erkennen, ob die CUL noch lebt (ist mir bei tests mehrfach "gestorben" ohne dass FHEM dies alarmierte)
Das ping habe ich noch nicht begonnen. Die neue FW wird es unterstützen. Prinzipiell würde ich dies allen modes anraten. Ob alle Timing brauchen... müssen diese selbst wissen

Ich verstehe diese Frage nicht.

Ansgar wollte wissen, die CUL FW abgegeben werden kann. Wo einchecken, wen informieren,...

[betateilchen]

Ansgar wollte wissen, die CUL FW abgegeben werden kann. Wo einchecken, wen informieren,...

*g* dann hättest Du in Deiner ersten Frage auch "abgeben" schreiben sollen und nicht "angeben", dann wäre es gleich verständlich gewesen

Ansgar bracht noch hilfe, wie er die CUL_FW angeben soll. Wo muss diese hin?

[rudolfkoenig]

=> generell biete ich an, das pairen in die vccu von CUL_HM zu verscheiben

Das darfst/musst du selbst entscheiden, da du fuer HM zustaendig bist.

weil es Pflicht für das System ist, zu wissen welche HW vorliegt.

Sehe ich nicht so. At1 kann man auch ohne FW/HW-Pruefung absenden, und beim Parsen wird diese Version sowieso nicht mehr abgefragt, sondern nur nach FF geprueft. Vom Feature sollten die Benutzer von anderen/neuen CUL Derivaten ohne eine explizite Eintragung in irgendwelche Listen profitieren koennen.

Dass man die Nachrichten mit ein paar blanks versieht macht das ganze nur lesbar.

Wenn man nur HM sieht/hat, mag das praktisch sein, ein CUL bedient selbst mit rfmode=HomeMatic auch noch andere Protokolle.

Gerne kann man überlegen, nicht-HMmodes unformatiert zu lassen. Woran erkenne ich das?

An dem A am Anfang der Nachricht.

Prinzipiell würde ich dies allen modes anraten.

Mir sind solche Probleme noch nicht vorgekommen, und wenn es passieren sollte, dann wuerde ich den Bug fixen, und nicht in workarounds investieren.

Wo einchecken, wen informieren,...

Am besten mir zusenden, oder in irgendeinem Forum was ich betreue reinstellen.

[martinp876]

Sehe ich nicht so. At1 kann man auch ohne FW/HW-Pruefung absenden...

Die HM-version anzeigen halte ich für sehr sinnvoll, unabhängig vom Timer - ist aber deine Entscheidung
Die idee At1 einfach zu senden und dann kommt der timer oder nicht ist - wie du erkannt hast teil des Konzepts. Leider darf ich das aber nicht, da sich z.B. die CUNO beim At1 erhängt hat. Wenn du mir also versicherst, dass man At1 an alle HW/FW varianten senden darf bin ich zufrieden. Oder immer ab FW 1.61 - auch ok.

Wenn man nur HM sieht/hat, mag das praktisch sein, ein CUL bedient selbst mit rfmode=HomeMatic auch noch andere Protokolle.

ich kann es gerne am "A" für HM fest machen. Ich würde den log eh nach dem "großen if" einbauen. dann kann ich die Änderung in
"} elsif($fn eq "A" && $len >= 20) {              # AskSin/BidCos/HomeMatic"
durchführen. Hätte ich vor einiger Zeit schon fast so umgebaut . Leider sind im Code 2 vorzeitige Returns drin. Insbesondere den ersten halte ich für .... unsauber.

Wenn man das gerade zieht wäre es m.E. besser - und jeder könnte - falls gewünscht - sehr einfach den log formatieren.

Mir sind solche Probleme noch nicht vorgekommen, und wenn es passieren sollte, dann wuerde ich den Bug fixen, und nicht in workarounds investieren.

hm -
- es ist mir vorgekommen
- man sollte einen bug fixen - lobenswert.
- end2end überwachung ist ein anderes Thema und eine gängige methode. hat nichts mit schlechtem bugfixing zu tun. Es ist schnittstellen-unabhängige überwachung, OS unabhängig,...

[martinp876]

habe gerade einmal mit CUNO V1.57 getestet. Wenn man At1 sendet wird der receiver umgeschaltet und die CUNO empfängt nichts mehr. Wenn man dann einmal powered bleibt die CUNO (an ethernet) stumm. Erst wenn man etwas senden will wird das Problem bemerkt und die CUNO startet wieder. In der Zwischenzeit werden unendlich lange keine Daten mehr Empfangen

=> was ist dein Vorschlag, diese beiden Ereignisse zu bearbeiten? Beides ist wohl nicht beabsichtigt.

anbei ein 00_CUL mit Anpassungen im Parser - leichtes Tuning, ein paar doppelte lenght() entfernt... denke es ist in deinem Sinn. Entwickler, die an harten, lesbaren Daten interessiert sind können das in "ihren" if einbauen. Daher ist der Log am Ende - wie angesagt

[rudolfkoenig]

Wenn es mit At1 in irgendeiner Version Probleme gibt, dann wuerde reichen es mit dem Versionsnummer zu pruefen. Besser faende ich zu sagen, dass die neue FHEM Version ein aktuelles culfw benoetigt, schliesslich funktioniert CUL_HM mit einer culfw Version < 1.38 auch nicht. Wichtig: das muss in CHANGED erwaehnt werden.
Ich sperre mich aber dagegen, dass man diesen Feature nur fuer den CUL_V3 freischaltet, und SCC/COC/etc Benutzer ausschliesst, oder einzeln "reinlaesst". Vorallem sollte aber dieses culfw Feature erstmal "richtig" verfuegbar sein.

Bei den Debug-Ausgaben scheint meine Absicht auch nicht angekommen zu sein: ich werde nicht fuer jeden Protokolltyp in CUL eine extra-Behandlung schreiben, dafuer gibt es doch die Module. Warum sperrst du dich dagegen, diese formatierte Ausgaben in CUL_HM zu machen?

[martinp876]

wie du sicher gesehen hast arbeitet 00_CUL mit und ohne timestamp - mit geht es besser. Mir wäre es egal, einfach At1 zu senden - dann kommt der timestamp oder nicht. Was nicht passieren darf ist, dass CUL das Arbeiten beendet. Meine CUNO, aktuell auf 1.57, beendet einfach das Empfangen - kommentarlos. Einige HW-Typen können den timestamp mangles HW-timer nicht unterstützen (wurde mit gesagt).

=> wenn alle FW-versionen At1 und Ap ab Version 1.60 unterstützen - also in keiner Form blockieren - ist mir das Recht. Ausklammern will ich nur die, welche am Kommando sterben.

Das mit dem Ping werde ichbei zeiten untersuchen.

Bei den Debug-Ausgaben scheint meine Absicht auch nicht angekommen zu sein:

schon - nur bin ich anderer Meinung.

ich werde nicht fuer jeden Protokolltyp in CUL eine extra-Behandlung schreiben,

musst du nicht, hab ich gemacht. Wer was braucht kann es einkippen

Warum sperrst du dich dagegen, diese formatierte Ausgaben in CUL_HM zu machen?

weil CUL_HM das nicht leisten kann. Das "mikro-timing" wird vom io gemacht. Insbesondere beim Senden. Ausserdem sehe ich nur dort IO-spezifika. Bei HMLAN sind dies nocht deutliche mehr.
Das IO sendet ggf pings und steuerkommandos an das IO (bei HMLAN). All das kann ich in CUL nicht sehen.
=> wenn ich es in CUL_HM macht fehlt entscheidende Info. Zudem - oder als Alternative  - müsste CUL_HM die IOs unterscheiden (HMLAN vs CUL).
Ich denke/vermute du hast genug echtzeit Erfahrung dass dir klar sein muss, dass der probe-punkt möglichst nahe an der Schnittstelle sein MUSS. Daher verstehe ich deine Aussage garnicht.

Dass man die Ausgaben lesbar macht sollte sich von selbst verstehen (also nicht klartext, aber ein paar fixe Blanks). Leider lese ich unformatierte hexzeilen nicht so flüssig wie du - und benutze dies Anfänger-editoren mit highlighting-features (auch gut bei standard-formatierten code )

Warum lesbare Info (HW-Version) nicht angezeigt werden soll verstehe ich nicht. Wenn aber die FW robust ist soll es mir egal sein. 

[rudolfkoenig]

Das "mikro-timing" wird vom io gemacht. Insbesondere beim Senden.

Aber wir reden doch hier vom Empfang, und da wird unmittelbar das ParseFn in CULHM aufgerufen.

Wie auch immer: ich werde diesen Patch leicht abgewandelt einbauen, aber erst nachdem das passende Gegenstueck in culfw eingecheckt ist. Dafuer muss aber Ansgar sein 80k-Timer-Patch in handlicheren Stuecken zur Verfuegung stellen.

[martinp876]

Aber wir reden doch hier vom Empfang,

nein. ich muss senden und empfangen korrelieren - eines alleine bringt mich nicht weiter - würde es dir reichen?

und da wird unmittelbar das ParseFn in CULHM aufgerufen.

nein, der dispatcher. Der sucht erst einmal herum und probiert, was schon einmal Zeit kostet - variable.
Ausserdem arbeiten wir mit einen preemptiv OS - das hat schon in einigen logs einen sichtbaren delay gezeigt (logisch).
Das OS kann zwar immer zeitlich reinfunken (was es auch macht) - aber jeder vermeidbare Delay ist auf diesem Level zu vermeiden - zwingend. Evtl. liegt es an der perl-eigenen Trägheit, dass das OS doch so häufig hier zwischen kommt.

Ich weiss, dass ich bei dir auf taube Ohren stosse, wenn ich von timing und timing-problemen rede - und dass andere Familien eh höheren Anforderungen haben (Z-Wave ist , denke ich deine standard Antwort hier). Ich sehe keine andere sinnvolle Möglichkeit, präzise aussagekräftige Traces zu erhalten.

Die übrigen Aktionen sind eh notwendig (timing-berechnung,...)

Klar ist auch, dass dies Developer-logs sind - die nicht jeder lesen will. Eine Art core-dump - den lesen die User auch nicht. Userlogs kommen aus CUL_HM.

ich werde diesen Patch leicht abgewandelt einbauen

danke. Wenn das format erhalten bleibt

aber erst nachdem das passende Gegenstueck in culfw eingecheckt ist.

wenn du meinst. Sicher klärst du die Frage nach dem handling des At1 bei andern HW-versionen bei identischen FW version.