FHEM - Hausautomations-Systeme > SlowRF

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

<< < (2/7) > >>

rudolfkoenig:

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

--- Ende Zitat ---
Ich meine CUL_HM sollte auf verbose 4 die passend formatierten Daten anzeigen.


--- Zitat ---würde der patch eventuell mehr zustimmung erhalten, wenn das attribut gestrichen wird?
--- Ende Zitat ---
Ich habe nichts gegen das Attribut, ich will nur nicht neben den HM-spezifischen Timing-Aenderungen auch noch generell Logging, Parsen, etc umbauen.

noansi:
Hallo Rudolf,


--- Zitat ---Ich meine CUL_HM sollte auf verbose 4 die passend formatierten Daten anzeigen.
--- Ende Zitat ---
Ist zwar möglich, aber die Ankunftzeitinformation wird deutlich schlechter und insbesondere die Sendezeitinformation wird unbrauchbar.


--- Zitat ---Bei der kleinen RSSI Optimierung kann ich auf Anhieb nicht sehen, ob es fuer die anderen Protokolle auch funktioniert.
--- Ende Zitat ---
Wird auf die gleichen "Anfangsbuchstaben" angewendet mit gleicher "Erkennung", ob ein RSSI mitgeliefert wird.
Er wird weiterhin aus den letzten beiden Zeichen gewonnen. Die letzten beiden Zeichen werden daraufhin weiterhin von der dispatch message abgeschnitten. Die Stringlängeninformation wird durch -2 entsprechend korrigiert.
Außerdem wird die Zeit etwas früher genommen (nach Deiner üblichen Zeittoleranz irrelevant) und die Information "wiederverwendet", ebenso wie "Anfangsbuchstabe" und die Stringlänge.
$dmsgLog entfällt, da es nicht wirklich erforderlich ist.
Alles nicht dramatisch.
Auch bei HM messages ist der RSSI nicht Teil der message, sondern ebenfalls nur angehangen, gehört bei der Log message also hex abgeschnitten, wie bei anderen Protokollen auch. Der Patch behebt damit einen Bug beim HM Parse Logging.
Siehe auch Franks Beispiel, len=0x0c aber 13 Bytes in der Log message.
Das kannst Du natürlich auch anders mit weniger Eingriff lösen.

Was Frank aber vor allem neben der Timing Korrektur fehlt, ist das verbose 4 HM Sende Logging, weil er dann gar nicht auf verbose 5 einstellen müßte.

--- Code: ---+      Log3 $name, 4, "CUL sent: $name ".join(" ",(unpack'A2A2A2A4A6A6A*',$bstring)); #noansi: for support guys better readable https://forum.fhem.de/index.php/topic,120268.msg1156754.html#msg1156754

--- Ende Code ---
Und auch hier ist die möglichst genaue Zeit des Abschickens interessant, wie schon angeführt.

Dann wären ihm auch die beiden von mir schon genannten Zeilen bezüglich verbose 5 egal.


--- Zitat ---Wenn es Timingprobleme gibt, dann sollte die Aufgabe im Firmware geloest werden.
--- Ende Zitat ---
Ganz meine Meinung. Kannst Du gerne übernehmen, der Patch fetzt dann aber richtig durch den Code.  ;)

Gruß, Ansgar.

frank:
hallo rudi,

ich tue mich schwer damit, genau zu verstehen, an welcher stelle deine "bauchschmerzen" entstehen.

meine spekulation:
- du möchtest die loginfo der sendemsg weiterhin in devio behalten, nicht in 00_cul.
- in devio möchtest du aber keine hm-spezifischen fallunterscheidungen.

falls das in die richtige richtung geht, wäre es dann eventuell möglich, die aktuelle loginfo aus devio:

--- Code: ---2021.05.15 10:05:27.801 5: SW: As0A228002F11234653BE000
--- Ende Code ---

auf verbose=4 zu ändern?

der sende string braucht nicht "zerlegt" zu werden, also ohne formatierung. 
allerdings müsste der devicename vom entsprechenden cul noch eingebaut werden, um bei multi-io betrieb eine eindeutige zuordnung zu bekommen.
der devicename fehlt eigentlich auch in 2 weiteren log infos, wenn ich mir das obige log anschaue. die CUL/RAW-einträge und die info mit der dly-info zeigen ebenfalls nicht das sendende io. 

die logzeile würde dann zb so aussehen:

--- Code: ---2021.05.15 10:05:27.801 4: SW: SCC As0A228002F11234653BE000
--- Ende Code ---

rudolfkoenig:

--- Zitat ---Ist zwar möglich, aber die Ankunftzeitinformation wird deutlich schlechter und insbesondere die Sendezeitinformation wird unbrauchbar.
--- Ende Zitat ---
Wenn Timing so wichtig ist, dann muesste das von Firmware mitgeschickt werden. FHEM ist nicht realtime faehig, und ich habe nicht vor, daran was zu aendern.


--- Zitat ---ich tue mich schwer damit, genau zu verstehen, an welcher stelle deine "bauchschmerzen" entstehen.

--- Ende Zitat ---
An vielen Stellen :)
Lowlevel read und write gehoert mAn auf level 5. Dass die Daten Tropfchenweise reinkommen, wundert mich, das ist bei mir (ueber USB anbundenes CUL, SlowRF Daten) nicht der Fall, ich kriege eine Zeile pro Nachricht. Ich tippe bei Dir auf ueber Netzwerk angebundenes CUL, fuer diesen Fall habe ich das CUL Attribut noRawReadLog eingebaut.

Dass man bei mehreren IO-Geraeten den Namen sehen will, versetehe ich, das habe ich fuer DevIO_SimpleWrite, CUL_Read und CUL_ReadAnswer eingebaut.

noansi:
Hallo Rudolf,


--- Zitat ---Dass die Daten Tropfchenweise reinkommen, wundert mich, das ist bei mir (ueber USB anbundenes CUL, SlowRF Daten) nicht der Fall, ich kriege eine Zeile pro Nachricht.
--- Ende Zitat ---
Richtig, ein nativ USB fähiger CUL schickt seinen Buffer auch meißt in einem Rutsch raus (es sei denn, der USB Transferbuffer wird vor dem Compilieren sehr klein gewählt).
Alle nativ seriell angebundenen CULs schicken Ihren Buffer Zeichen für Zeichen. Und so schnell, wie FHEM die aus seinem Empfangsbuffer abholen kann, so tröpfchenweise kommen sie rein. Mal einzeln, mal mehrere auf einmal, wenn FHEM sehr beschäftigt ist, dann kann es auch mal eine Nachricht komplett sein.
Für interessierte Mitleser, die Nanos sind auch nativ seriell angebunden, nur via USB Interface Chip.


--- Zitat ---Wenn Timing so wichtig ist, dann muesste das von Firmware mitgeschickt werden. FHEM ist nicht realtime faehig, und ich habe nicht vor, daran was zu aendern.
--- Ende Zitat ---
Wenn User nun mal unbedingt die Standard oder a-culfw verwenden möchten, dann kommt vom CUL keine Timing Information und damit bleibt Frank als einem der Powersupporter dort nur noch das raw log, um Anhaltspunkte zu Problemursachen bezüglich Timing zu finden.

Gruß, Ansgar.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln