@derauge Ich mache das in der Regel auf einem Linux mit screen. Damit kannst du direkt sehen ob was kommt. Zum Beispiel
screen /dev/ttyUSB0 115200 natürlich mit deinem Schnitstellepfad ersetzen (serial/by-id Pfad oder udev Regel nutzen macht Sinn).
Hallo zusammen, hat jemand zufällig das selbe Problem mit der APK von v3.1.8? Die App lief bis vor ein paar Tagen/Wochen auf meinem Galaxy S24 anstandslos. Jetzt kommt beim starten nur noch diese Meldung:
Habe noch ein Galaxy S10 im Zugriff und auch dort der selbe Mist. Über den Browser funktionierts wunderbar, egal ob Computer oder Smartphone. Hab natürlich schon versucht die App zurückzusetzen, alles bisher ohne Erfolg. Meine Lizenz läuft noch einige Monate.
@PLCHome-0 Ich habe es mehrfach versucht, leider ist spätestens nach ein paar Stunden die Ordnung wieder dahin. Zum Glück werden die Zellspannungen immer korrekt im selben Datenpunkt abgelegt, sonst wäre jedesmal mein logging gestorben. Wenn ich gesamten Baumstrucktur lösche, muss ich leider jedes mal aufs Neue das influx log aktivieren. Ich bin ja hauptsächlich an den Zellspannungen interessiert. Das VenusOs zeigt per BMS CAN leider nur min/max Zellspannung, aber eben nicht alle.
Es scheint wirklich nur die 'bat 1' Abfrage zu betreffen, zumindest ist mir bei den anderen Feldern noch nix aufgefallen.
Ich stelle nochmal meine Frage: Wie sieht es denn mit soh bzw stat aus? Willst du das noch einbauen?
Gruß Markus
@plchome-0 Hab nochmal alle Daten gelöscht um zu prüfen ob direkt wieder das gleich Problem auftritt, aber dem ist nicht so. Ich werde es beobachten und dir eine Datei schicken.
@PLCHome-0 Kann es sein das wir hier noch ein RegEx Problem haben? Irgendwie passt da was nicht. Die Bezeichnungen der Spalte sehen verschoben aus und die Werte teilweise auch. Die Daten holt der Adapter jetzt stabil aus dem Pack, jetzt brauchen wir wohl noch Feinschliff.
@derauge Ich mache das in der Regel auf einem Linux mit screen. Damit kannst du direkt sehen ob was kommt. Zum Beispiel
screen /dev/ttyUSB0 115200 natürlich mit deinem Schnitstellepfad ersetzen (serial/by-id Pfad oder udev Regel nutzen macht Sinn).
@plchome-0 Kurzes Feedback: v.0.0.10 läuft gut und macht bis jetzt keinen Ärger mit der Pytes-V5. Ich habe das logging allerdings auf debug zurückgeschraubt, sehe also nicht mehr alles. Es gab keinen Timeout mehr. Wie sieht es denn mit soh bzw stat aus? Bringst du noch eine Update oder ist das schon integriert? Hatte im Hinterkopf erstmal die Timeouts bekämpfen und dann den Rest. Die einzige Meldung die immer kommt:
debug | Search can't be optimized because wildcard not at the end, fallback to keys!: function(doc) { if (doc.type === 'state') emit(doc._id, doc) }
Vielleicht sollte man in der Adapterkonfig nochmal hervorheben welches Modell für welchen Battery-Typ passt oder den Selektor einen weiteren Eintrag verpassen. Dokumentation lesen macht halt lange nicht jeder.
@PLCHome-0 Mit dem angepassten RegEx scheint es zu passen, habe keine Meldung mehr bekommen.
Unter pylontech.0.ES1000626P010443.power.power_events erwartet der Adpater ebenfalls eine Zahl.
Mir is noch nicht ganz klar was "0x8000000 DSG" bedeutet, muss ich mal weiter beobachten falls es nochnmal kommt.
@PLCHome-0 Noch eine kleine Anmerkung, da passt die Zuordnung nicht. Muss ich mal beobachten ob das nur bei 100% auftritt (habe den Fall mit fetchCmdSerial.js gesichert):
State value to set for "pylontech.0.ES1000626P010443.battery16.coulomb" has to be type "number" but received type "string"
@PLCHome-0 Update: Neben meinem Consolenkabel (USB->RJ45) mit FTDI Chip, habe ich noch einen
Waveshare FT232RNL (FTDI), UGREEN mit PL2303 (Prolific) und den besagten LogiLink AU0034 (FTDI) zur Verfügung. Bei dem PL2303 werden offensichtlich immer nur kleine Datenmengen eingelesen und es gibt das totale Chaoslog. Bei den FDTI Konsorten kann ich keine wesentliche Unterschiede feststellen. Im weiteren Verlauf wurde der LogiLink benutzt.
Kommen wir mal zurück zum Problem: Egal ob mit Pause oder ohne, es kommen immer wieder Timeouts. Abfrageintervalle getestet 1, 3 und 5 Minuten ohne/mit Pause von 100 ms bis 1000 ms. Die Tendenz, dass die Abfrage in einen Timeout läuft, ist ohne Pause auf jeden Fall höher. Mit Pause von 1000 ms und 5 Minuten Intervallen läuft der Adapter 2, 3 oder auch 5 Stunden ohne Probleme. Es kann aber auch passieren das ein oder mehrer Timouts hintereinader stattfinden und danach läufts wiede für 3 Stunden.
Welche Informationen gerade abgerufen werden scheint auch unerheblich zu sein. Abbrüche hatte ich sowohl bei pwr, bat, log, info und time.
Um wirklich sicher auszuschließen das es mit der Schnittstelle nix zu tun hat, habe ich kurzerhand ser2net bemüht und die Daten nicht direkt geholt. Das hat leider gar keinen Unterschied gemacht.
So langsam gehen mir die Ideen aus, bis auf die Tatsache das eine Pytes-V5 an der Console nicht dafür gemacht zu seien scheint. Die Abfragen für soh, stat waren immer inaktiv beim testen. Hier müsste für stat ja noch eine Anpassung rein das es die Abfrage stat 1 nicht gibt.
