FHEM - Hausautomations-Systeme > SlowRF

[00_CUL.pm] patch für verbesserte homematic kommunikation

(1/8) > >>

frank:
hallo rudi,

vielleicht hast du es ja nur übersehen.
hier https://forum.fhem.de/index.php/topic,120603.msg1160891.html#msg1160891 hat noansi "nebenbei" auf einen patch für 00_CUL.pm hingewiesen:


--- Zitat ---Hier https://forum.fhem.de/index.php/topic,120268.msg1160889.html#msg1160889 übrigens noch Verbesserungen an 00_CUL.pm auch als diff, wie in dem Thread entstanden.
Es verbessert das Timing für Folgesendemessages, die zuvor beim User zu früh gesendet wurden, außerdem das Message Logging für den HM Support.
--- Ende Zitat ---

ich wäre sehr erfreut, wenn du noansis änderung übernehmen würdest.

rudolfkoenig:

--- Zitat ---vielleicht hast du es ja nur übersehen.
--- Ende Zitat ---
Ich verfolge HomeMatic spezifische Diskussionen nicht.
PM blockiere ich nicht bewusst.
 
Der Diff ist mir so leider zu gross und zu unspezifisch, da wird von Timing-Aenderungen ueber Parsen bis generische Logausgaben viel umgebaut. Ich habe nichts gegen ein HM-Only patch, insb. wenn die Aenderungen klar abgegrenzt sind, und der Grund fuer mich verstaendlich ist.

noansi:
Hallo Rudolf,

die Änderungen sind HM spezifisch.

Das Logging hier:

--- Code: ----  Log3 $name, 5, "CUL/RAW: $culdata/$buf";
+#  Log3 $name, 5, "CUL/RAW: $culdata/$buf"; #noansi: still really of interest, how a fillup from serial IO is in progress? Loglevel 6?
--- Ende Code ---

--- Code: ---+    Log3 $name, 5, "CUL: $rmsg"; #noansi: this is more of interest in most cases and better readable
--- Ende Code ---
kannst Du natürlich auf altem Stand lassen. Kostet mAn aber nur unnötig Rechenzeit (Timingauswirkungen) und macht das Log insbesondere bei seriellen devices unleserlich, weil man quasi zuschaut, wie Zeichen reintröpfeln und darüber die eigentliche message kaum findet.
Für spezielle Probleme möglicherweise nochmal mit Loglevel 6 interessant, aber eigentlich inzwischen eher historisch aus der CUL und devio Entwicklung begründet, denke ich.

Das HM Logging wieder formatiert auszugeben war Userwunsch, Frank kann Dir den Link sicherlich raus suchen.
Damit verbunden ist eine kleine Optimierung bei der rssi Extraktion und $len Ausnutzung.

Der Rest betrifft HM Timing von Antworten und Folgemessages.
Die positiven Effekte kann Dir Frank sicherlich auch am zugehörigen Thread darlegen. Sicherlich auch mit mehr von seinem super Logging, wenn es zur Erklärung nötig ist.

Gruß, Ansgar,

rudolfkoenig:
Ich verstehe den Wunsch, hat aber alles seine Probleme (s.u.), und wenn alles in einer Tuete kommt, weiss nicht, welche ich einzeln weglassen kann.

Logging: loglevel 6 ist nur bei verbose 5 ein Performance-Gewinn, und zieht eine Tuete weiterer Probleme hinter sich. Das Troepfchenweise ist dann interessant, wenn kein NL kommt, und verbose 5 ist kein Normalfall. Formatieren speziell fuer HM muss das HM Modull uebernehmen, sonst kann man ja das HM-Modul gleich ins CUL.pm integrieren. Wenn es Timingprobleme gibt, dann sollte die Aufgabe im Firmware geloest werden.

Bei der kleinen RSSI Optimierung kann ich auf Anhieb nicht sehen, ob es fuer die anderen Protokolle auch funktioniert.

Ich hoffe, dass man dem Frank auch ohne diese Aenderungen helfen kann.

frank:

--- Zitat ---Ich hoffe, dass man dem Frank auch ohne diese Aenderungen helfen kann.
--- Ende Zitat ---
der ansgar hat dem frank mit diesem patch bereits optimal geholfen.  :)

allerdings dachte dieser frank ganz unbedarft, dass den vielen anderen cul usern, die es da draussen im dschungel der homematic-io-fw/modul-welt in grosser zahl gibt, ebenfalls geholfen werden könnte.
vor allem "neuen" usern, die an jeder ecke lesen, dass ein cul für homematic das beste wäre und erschrocken reagieren, wenn sie deshalb beim ersten problem sofort "gemobbt" werden.


zum logging:
beim logging wünsche ich mir eigentlich nur, dass das logging mit verbose=4 mindestens wieder so wird, wie es schon mal gewesen ist.


--- Zitat ---verbose 5 ist kein Normalfall
--- Ende Zitat ---
eine analyse der homematic kommunikation mit einem cul ist aktuell aber leider nur mit verbose=5 machbar, da die messages, die der cul sendet, irgendwann aus verbose=4 "verbannt" wurden. also der normalfall.

im forum habe ich logs von ende 2016 gefunden, in denen die sende messages (CUL_send) noch mit verbose=4 zu sehen sind:

--- Code: ---2016.09.05 21:09:01.505 4: CUL_Parse: CUL0 A 0C B9 A641 278291 1DA462 01EF0031 -49.5
2016.09.05 21:09:01.608 4: CUL_send:  CUL0As 0D B9 8002 1DA462 278291 0101C800
--- Ende Code ---

aktuell ist erst bei verbose=5 eine ausgabe durch DevIO.pm zu sehen (SW), die mit CUL_send vergleichbar ist.

--- Code: ---2021.05.15 10:05:27.687 5: CUL/RAW: /A14
2021.05.15 10:05:27.689 5: CUL/RAW: A14/22A45F
2021.05.15 10:05:27.690 5: CUL/RAW: A1422A45F/653B
2021.05.15 10:05:27.691 5: CUL/RAW: A1422A45F653B/E0F1
2021.05.15 10:05:27.692 5: CUL/RAW: A1422A45F653BE0F1/1234
2021.05.15 10:05:27.693 5: CUL/RAW: A1422A45F653BE0F11234/8110
2021.05.15 10:05:27.694 5: CUL/RAW: A1422A45F653BE0F112348110/4C00
2021.05.15 10:05:27.695 5: CUL/RAW: A1422A45F653BE0F1123481104C00/1723
2021.05.15 10:05:27.696 5: CUL/RAW: A1422A45F653BE0F1123481104C001723/0223
2021.05.15 10:05:27.697 5: CUL/RAW: A1422A45F653BE0F1123481104C0017230223/0947F
2021.05.15 10:05:27.698 5: CUL/RAW: A1422A45F653BE0F1123481104C00172302230947F/A29
2021.05.15 10:05:27.699 5: CUL/RAW: A1422A45F653BE0F1123481104C00172302230947FA29
/

2021.05.15 10:05:27.700 4: CUL_Parse: SCC A 14 22 A45F 653BE0 F11234 81104C00172302230947FA29 -53.5
2021.05.15 10:05:27.701 5: SCC: dispatch A1422A45F653BE0F1123481104C00172302230947FA::-53.5:SCC
2021.05.15 10:05:27.706 5: SCC sending As0A228002F11234653BE000
2021.05.15 10:05:27.707 5: CUL 653BE0 dly:93ms
2021.05.15 10:05:27.801 5: SW: As0A228002F11234653BE000
--- Ende Code ---

das macht nicht nur keinen spass mehr sich durch diese logs zu wühlen. es wird nahezu unmöglich probleme zu entdecken, besonders wenn man homematic mit mehreren io betreibt.



--- Zitat ---Formatieren speziell fuer HM muss das HM Modull uebernehmen, sonst kann man ja das HM-Modul gleich ins CUL.pm integrieren.
--- Ende Zitat ---
das ist doch sicherlich ein wenig übertrieben.
ohne es genau zu wissen, behaupte ich mal, 00_CUL war das erste modul, das das logging für homematic vorgegeben hat. daran haben sich später 00_HMLAN, 00_HMUARTLGW und 00_TSCUL orientiert, um einigermassen kompatibel zu sein.
warum auch immer ist 00_CUL dann scheinbar (mit version 13833 vom 27.3.2017) aus dieser "allianz" ausgestiegen.



zum timing:


--- Zitat ---Wenn es Timingprobleme gibt, dann sollte die Aufgabe im Firmware geloest werden.
--- Ende Zitat ---
antworten vom cul an das device werden ja bereits in 00_CUL (schon immer?) verzögert gesendet, damit hier das "timing" passt. an dieser stelle wird also das timing bestimmt.

probleme mit der aktuellen 00_CUL gibt es in der regel nur, wenn der cul 2 messages nacheinander an das device senden muss, da dann nur die erste message verzögert gesendet wird, aber die 2. message bereits unmittelbar nach der ersten. diese fehlende 2. verzögerung, soll der patch "bereinigen".
die aktuelle implementierung hat diesen umstand scheinbar "übersehen".

dazu hat ansgar zusätzlich ein attribut vorgesehen, womit diese 2. verzögerung einstellbar wird. default 60ms.
ich erziele mit der default verzögerung von 60ms beste ergebnisse.

würde der patch eventuell mehr zustimmung erhalten, wenn das attribut gestrichen wird?
dann müsste man sich vielleicht noch mal über diesen dann festen wert gedanken machen.

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln