addData overflow #62
Comments
|
Sorry, falsches Fenster. Daher nun im Richtigen Faden. Hallo @Ralf9
|
|
@sidey79 |
|
Hallo, hier mal eine andere Konstellationen der Ausgaben.
|
|
Hallo, ich habe mir nochmal bestmöglich die Zusammenhänge angesehen oder probiert wann der Fehler auftritt. Meine Erkenntnisse sind wie folgt:
Vermutung:
Eine Zusammenstellung des Logfile, wo MC Steuerzeichen sichtbar sind und bei sämtlichen anderen Nachrichten nicht: (geschriebenes Logfile mit NotePad++ geladen und angesehen)
@sidey79 / @Ralf9 könnt Ihr das vielleicht bestätigen oder auch validieren. MfG |
|
mTrunc=1 bedeuted, daß der buffer voll war und es ein bufferMove gegeben hat. Beim bufferMove müsste normalerweise auch die messageLen verringert werden. Da scheint irgendwas nicht zu passen. Evtl bekommen wir neue Erkenntnisse, wenn Du am Anfang der
Bei diesem häufigen auftreten kannst Du auch mal die debug Ausgabe aktivieren. |
|
Ich habe nun mal
eingebaut und schaue mal was das System sagt. Eines ist auf jedenfall schon erkennbar, das ein bufferMove vorhanden ist und die msglen sich immer verringert.
Wenn ich die Parameter
einbaue, so schließt er mir sofort die Schnittstelle "closed" und meine TX Lampe bleibt dauerhaft an. |
|
Hier mal noch ein Auszug mit Dataoverflow.
Ich werde sofort nach einem Schälchen Heeßen noch einmal versuchen die Debugausgaben einzufügen welche beim ersten mal sofort dem Empfänger zum "schweigen" brachten. |
|
Hier kommt mal noch ein Auszug, wo man erkennen kann, das der Empfänger kurzzeitig "dich" macht für Befehle, wenn ich das richtig deute.
|
|
Das mit dem BufferMove sieht gut aus.
Dies passt hier aber nicht. Das "addData overflow" kommt auch bei MU=0;MC=0 |
|
Hallo, habe ich das richtig verstanden?
sollte erst auftauchen wenn eine Nachricht empfangen wurde? Ich habe das bufferMove teilweise auch wenn ich den Empfänger abstecke und nur an ein ein System anstecke, also sofort nach dem CC1101 erkennen. .... soeben habe ich den bufferMove! mal laufen lassen und dann erschien addData .... und keine Nachrichten werden empfangen. :-( MfG |
|
Soeben habe ich es nochmal mit probiert. Sobald ich an die Schnittstelle gehe
.... und es läuft und läuft .... |
|
Ich habe mal noch etwas entlocken können. |
Du kannst mal testen ob es besser wird, wenn Du das Das bufferMove wird auch bei Add pattern verwendet, mir ist aber die funktionsweise nicht klar |
Es ist wahrscheinlich nur brauchbar, wenn das "addData overflow" dabei vorkommt. |
|
Wenn ich die DEBUGDETECT 2 herausnehme
|
|
ich denke, da kommen wir ohne Sidey nicht weiter. |
|
hier kommt noch eine Variante wo dann der Empfänger den "Empfang einstellt" und nix mehr erkennt. ... schluss für heut |
|
Ich habe es noch nicht geschafft, mir das genauer an zu sehen. |
|
Ich habe mir das nun einmal ein wenig angesehen: @HomeAutoUser Grüße Sidey |
|
@sidey79, |
|
ich habe bei der dev-r33_cc1101 bei addData einige debug Ausgaben ergänzt |
|
@Ralf9 Mit dem RSSI das funktioniert nun in der letzten Version. |
Added additional printOut, to identify buffer content if addData fails #62
|
Ich weiss noch nicht genau, was wir alles brauchen. Ich habe einen Buffer Dump eingebaut, wenn der Fehler auftritt. Wäre gut, wenn Du die aktualisierte Version compilierst und mir hier die Ausgabe schickst. Buffermove schließe ich als Fehlerquelle mittlerweile eigentlich aus, für mich sieht es eher so aus, als ob processMessage weder eine MC, MS noch MU Ausgabe schafft. mTruncated ist aber gesetzt, das sehen wir. |
|
@sidey79 |
|
Debug Meldungen sollten mit der Compiler Konfiguration nur kommen, wenn addData fehl schlägt. |
|
@sidey79 Ich würde das System mit Verbose 3 | Debug 0 laufen lassen nach deiner jetzigen Aussage. |
|
Also wir haben zwei Probleme
Gut scheint ja zu sein, dass keine add data overflow Meldungen mehr kommen. Mein Schritt wäre nun einmal alle Änderungen die wir für die Behebung des overflows gemacht haben zu sichten.. |
|
Hallo @sidey79 , Desweiteren bitte als Punkt 3. die Erkennung "alter" Protokolle auf der Liste mit haben. Seit dem Ich nun die FW testlaufe um unseren Fehler auf die Schliche zu kommen, werden keine Hideki Sensoren erkannt. Hier muss sich etwas geändert haben. Ich habe Testweise auch MC abgeschalten aber diese werden NICHT erkannt. Kann es sein, das durch die Umstellung nun die Protokolldefinition nicht mehr passt bzw. angebappt werden muss?
|
|
So sehen die Zeiten nun aus, wenn ich MC aktiv habe.
Aus alten Logfiles habe ich entnommen, das die Zeiten bzw. Signale so registriert wurden.
Wieso nun diese nicht mehr erkannt werden ... keine Ahnung. Fakt ist, er springt nicht mehr auf die Protokolldefinition an. Versobe 5 aktiv.
EDIT: Ausgabe mit Debug
|
|
Nach ausgibigen Tests, muss die ToDo ergänzt werden Zu Punkt 3.
|
|
Ich habe so eine Idee, dass es damit zusammen hängt, dass ich die Variable messageLen in der Signaldecoder Klasse nicht mehr berechne, sondern auf valcount aus der Bitstore Klasse setze. Ist aber im Moment nur so eine Ahnung |
rised tolerance for compress_pattern 0.05 #62
|
Guten Morgen @sidey79 , Wie hier geschrieben, so ist der Punkt 3 immer noch Fehlerhaft!
werden nicht erkannte. Wiederum Signale welche kürzer sind, wie
werden erkannt. Springe ich zurück auf die andere FW so funktionieren diese wieder. MfG EDIT: Ich habe dazu auch den Verdacht, das betrifft auch "längere Signale wie bei MU" was ich auf die Schnelle sehen konnte in meiner Tabelle. Diesbezüglich muss ich aber nochmal genauer schauen. Anhaltspunkt beim debugen, Länge des Signales vermutlich. |
|
Ich hab meine Unit Tests laufen lassen. Hinsichtlich MC Decodierung gibt es noch einige Abweichungen. Die Daten werden decodiert, sind aber nicht identisch zur vorherigen Ausgabe. Den Punkt verstehe ich selbst noch nicht, da dieses veränderte Verhalten durch die Anpassungen ausgelöst wird. Für Ideen bin ich sehr dankbar. |
|
Ich bin die "Fehler" im Unit Tests durchgegangen und habe es mit einer Version vor unseren Anpassungen verglichen. Die Fehler sind identisch, das Fehlerbild hat also nichts mit unseren Anpassungen zu tun :( |
Removed some Debugs and prevent reset is last == null #62
|
Also Manchster (OSV2) funktioniert bei mir. |
#62 Additional debug, to find mc problem
|
Hallo @sidey79, du bist auf dem richtigen Weg. Mit der neuen FW werden wieder die Hideki Protokolle decodiert. Ob diese auch noch so zahlreich empfangen werden, zeigt die Zeit. Ist es gewollt, das du die Ausgabe
bei PARTIAL in FHEM - Empfängeransicht erzeugst zwischen den Signalempfängen? Die FW auf dem 868 Mhz Empfänger muss ich mir nochmal genau ansehen, da auf die schnelle da kein Empfang war, obwohl ich dort auch aller max 2min Signale empfange. Ist deine Frage noch aktuell? Wenn ja, wie meinst du diese? Möchtest du Signalausgaben? |
|
Das NV reset ist eine Debug Ausgabe. Die habe ich eingebaut, um mehr Infos zu dem Fehler zu erhalten. Das Modul kann damit aber nicht umgehen. |
|
Da ich in den Logs der letzten 2 Tage keinen addData Overflow Eintrag mehr habe, nehme ich an, dass wir dieses Problem gelöst haben. Ich schließe daher. Sollte das Problem noch bestehen, dann bitte wieder öffnen |
|
@sidey79, vermutlich haben wir uns zu früh gefreut. @Ralf9 mit deiner aktuellen FW trat dieser Fehler addData overflow!! auf.
|
|
Wenn der Fehler auch mit dem Code aus diesem Repo Auftritt können wir diesen Fall wieder öffnen. :) Zu Forks kann ich leider keine Aussage treffen. Das schaffe ich zeitlich nicht :( Dazu müsste ich wissen, ob alle Korrekturen in den Fork übernommen wurden. |
|
so wies aussieht, hast Du einen weiteren Fehler gefunden. @sidey79 Diesen commit habe ich bei mir wieder rausgenommen, da damit bei senden irgendwas nicht passt, wenn das Sendekommando mit SC beginnt |
|
Ich habe es gefixt. Jetzt müsste es passen. |
|
Kannst Du die Korrekturen als Patch bereitstellen? Ich kann zwischen Korrektur und Änderung nicht so Recht unterscheiden, da mir zu den Bugs die Daten fehlen.. Alles was mir als bug bekannt ist, habe ich meiner Meinung nach commitet. Grüße |
Dies wird schwierig, ich habe einiges umgeschrieben und verändert, da wird ein Patch wahrscheinlich nicht mehr funktionieren. Hier ist eine Korrektur: |
|
Deine Anpassung in doDetect ist sozusagen die Lösung zu #80 Ich habe die Codezeile nun so realisiert. Soll der compiler das beste draus machen :) |
calcHisto: Return if messageLen is 0 and we can not caluclate anything #62
moveLeft eines kompletten Puffers bei dem keine Daten übrig bleiben optimiert. #62
calcHisto: Return if messageLen is 0 and we can not caluclate anything #62
moveLeft eines kompletten Puffers bei dem keine Daten übrig bleiben optimiert. #62
In der aktuellen Version mit message kompression kann es unter bestimmten speziellen recht seltenen Umständen zu einem "addData overflow" kommen.
Vielleicht lässt sich mit diesen zusätzlichen Ausgaben der Fehler eingrenzen:
1484b46
siehe auch
#60 (comment)
The text was updated successfully, but these errors were encountered: