Test Adapter Pylontech v0.0.10
-
@plchome-0 Hast ein Update bekommen. Beim ersten Abrufen scheint mir "log" durchgerutscht zu sein.
-
@bios123 Danke, aber ich glaube das Problem bereits behoben zu haben
-
@PLCHome-0 Da passt was nicht. Hab gestern Abend mal die v0.0.8 angeschmissen und die Zellspannungen loggen lassen. Das scheint auch teilweise zu funktionieren. Seit heute Morgen dann anhaltende Fehler. Abrufintervall steht auf 5 Minuten:
2024-02-19 00:28:50.237 - error: pylontech.0 (58315) Error: timeout 2024-02-19 00:48:50.021 - error: pylontech.0 (58315) Error: timeout 2024-02-19 02:58:50.275 - error: pylontech.0 (58315) Error: timeout 2024-02-19 06:03:49.663 - error: pylontech.0 (58315) Error: timeout 2024-02-19 06:08:49.662 - error: pylontech.0 (58315) Error: timeout 2024-02-19 06:13:49.662 - error: pylontech.0 (58315) Error: timeout 2024-02-19 09:13:50.506 - error: pylontech.0 (58315) Error: timeout 2024-02-19 10:33:49.690 - error: pylontech.0 (58315) Error: timeout 2024-02-19 10:38:49.691 - error: pylontech.0 (58315) Error: timeout 2024-02-19 10:43:49.693 - error: pylontech.0 (58315) Error: timeout 2024-02-19 10:48:49.692 - error: pylontech.0 (58315) Error: timeout 2024-02-19 10:53:49.980 - error: pylontech.0 (58315) Error: timeout 2024-02-19 10:55:31.819 - error: pylontech.0 (64010) Error: timeout 2024-02-19 11:00:31.817 - error: pylontech.0 (64010) Error: timeout 2024-02-19 11:05:31.816 - error: pylontech.0 (64010) Error: timeout 2024-02-19 11:06:49.941 - error: pylontech.0 (64150) TypeError: Cannot read properties of undefined (reading 'battery01') 2024-02-19 11:07:21.962 - error: pylontech.0 (64171) TypeError: Cannot read properties of undefined (reading 'battery01') 2024-02-19 11:08:19.560 - error: host.iobroker Invalid request getRepository. "callback" or "from" is null 2024-02-19 11:09:46.013 - error: pylontech.0 (64209) TypeError: Cannot read properties of undefined (reading 'battery01') 2024-02-19 11:11:48.955 - error: pylontech.0 (64245) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:12:14.254 - error: pylontech.0 (64265) Error: timeout 2024-02-19 11:17:14.255 - error: pylontech.0 (64265) Error: timeout 2024-02-19 11:22:09.590 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:27:09.588 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:32:09.585 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:37:09.589 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:42:09.586 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:47:09.584 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:52:09.589 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 11:57:09.335 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 12:02:09.333 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 12:07:09.336 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') 2024-02-19 12:12:09.337 - error: pylontech.0 (64265) TypeError: Cannot read properties of undefined (reading 'power') -
@bios123
Danke fürs Testen.
Ich bin ein wenig verwundet, dass es bei dir nicht geht. Hast du US-Modell ausgewählt? Wie verbindest du den seriellen Port mit dem Rechner?In der Emulation läuft er bei mir. stat <batt> kann man nicht auf dem Akku abfragen wie bei den Pylontechs. Das passt aber nicht zu den Fehlermeldungen. soh <batt> sieht auch komisch aus.
PYTES> PYTES>stat 1 @ Invalid command or fail to excute. Usage: Statistic data show - stat $$ PYTES> PYTES>soh 1 @ Power 1 Battery Voltage SOHStatus È$ 0 3327 00000000 1 3327 00000000 2 3328 00000000 3 3328 00000000 4 3328 00000000 5 3328 00000000 6 3328 00000000 7 3328 00000000 8 3328 00000000 9 3328 00000000 10 3328 00000000 11 3328 00000000 12 3328 00000000 13 3328 00000000 14 3328 00000000 15 3326 00000000 Command completed successfully $$ PYTES>Am besten löscht du auch einmal alle Objekte in der Version 0.0.7 hat der da mist angelegt.
Und schalte doch mal die beiden Abrufe ab.
-
@PLCHome-0 die alten Objekte hatte ich bereits gelöscht um sicher zu gehen das alles sauber angelegt wird. SOH und STAT hab ich wie beschrieben ausgeschaltet. Das hilft aber nicht wirklich. Der Adapter ruft die Daten mal ab und mal nicht. Ich habe versucht den blockierenden Punkt zu finden. Das Kommando 'pwr' wird geschickt und ein Antwort gibt es auch, danach dann wieder Error: timeout. Ich vermute 'pwr' kann ich mit 'Batteriestromdaten herunterladen' abschalten? Wie schnell rufst du die Daten ab? Eventuell braucht die Pytes V5 nach jeder Anfrage einen Moment. Ich kann das zumindest nicht nachstellen, wenn ich manuell hintereinader ein Request abschicke. Ich rufe übrigens direkt per /dev/ttyUSB0 ab, Interface hängt am iobroker und 'US series' ist ausgewählt.
pylontech.0 2024-02-21 11:19:04.886 error Error: timeout pylontech.0 2024-02-21 11:18:59.932 silly if pylontech.0 2024-02-21 11:18:59.884 silly 16 - - - - - - - Absent - - - - - - - - - Command completed successfully $$ PYTES> pylontech.0 2024-02-21 11:18:59.852 silly - - Absent - - - - - - - - - 14 - - - - - - - Absent - - - - - - - - - 15 - - - - - - - Absent - - - - - - - - - pylontech.0 2024-02-21 11:18:59.810 silly - - - - - - 11 - - - - - - - Absent - - - - - - - - - 12 - - - - - - - Absent - - - - - - - - - 13 - - - - - pylontech.0 2024-02-21 11:18:59.766 silly - 8 - - - - - - - Absent - - - - - - - - - 9 - - - - - - - Absent - - - - - - - - - 10 - - - - - - - Absent - - - pylontech.0 2024-02-21 11:18:59.723 silly - - - - - - Absent - - - - - - - - - 6 - - - - - - - Absent - - - - - - - - - 7 - - - - - - - Absent - - - - - - - - pylontech.0 2024-02-21 11:18:59.680 silly - - - - - - - - 3 - - - - - - - Absent - - - - - - - - - 4 - - - - - - - Absent - - - - - - - - - 5 - pylontech.0 2024-02-21 11:18:59.397 silly PYTES> PYTES>pwr @ Power Volt Curr Tempr Tlow Thigh Vlow Vhigh Base.St Volt.St Curr.St Temp.St Coulomb Time B.V.St B.T.St Barcode DevType 1 53708 2164 24000 19000 19000 3352 3359 Charge Normal Normal Normal 52% 2024-02-21 18:15:57 Normal Normal ES1000XXXP010XXX E-BOX-48100V-D 2 - - - - - - - Absent -Gruß Markus
-
@bios123 sagte in Test Adapter Pylontech v0.0.8:
Noch mal danke für deine Geduld und das Interesse, den Adapter zu verbessern.
Aber ich muss gerade sagen, so richtig Plan habe ich nicht, warum es nicht gehen soll.
USB Adapter ist schon mal gut, wobei ein Kollege damit auch schon Probleme hatte.Meines Wissen nach hatte er aber auch Fehlermeldungen im
sudo dmesg | grep usbDer Adapter ruft die Daten mal ab und mal nicht.
Komisch
Ich vermute 'pwr' kann ich mit 'Batteriestromdaten herunterladen' abschalten?
Download the battery power data
The "pwr" command is always written to the console. The command “pwr -n-” is only written to the console if this is set here. Here you will find information about the positions of the individual batteries. It is needed for the object tree. If this is switched off, the information from the "pwr" command is not transferred to the ioBroker and the "pwr -n-" command is not issued.ja also pwr und pwr<n> alle weiten abrufe mit <n> sind dann auch nicht mehr möglich.
Wie schnell rufst du die Daten ab?
Der Adapter hat eine Que, wenn auf einen Befehl eine Antwort kommt, wird der nächste abgearbeitet. Da eine Pause zum Testen einzubauen ist möglich.
Vielleicht sollten wir zuerst einmal versuchen, das Time-out zu erhöhen.
Da der Adapter in Typescript geschrieben ist, sind die JS Dateien etwas unübersichtlich, da sie generiert wurden.Ach, das Intervall kannst du zum Test auch besser mal auf 2, 3 oder 5 Minuten stellen.
unter build/pylontech/WorkerAbstarkt.js findest du in Zeile 42:
this._timeout = 5e3;das sind 5000ms oder 5sec. Trag doch da einmal 10000 (10e3) oder 20000 (20e3) ein.
Vielleicht denkt der Accu zu lange
Bei dem Pylontech muss der Befehl mit einem \r abgeschlossen werden, vielleicht mag er auch das nicht. Du kannst in Zeile 72-mal versuchen, ob es mit \r\n besser geht.
this.sendData(this._activeCmd.cmd + "\r");oder am Anfang einen Umbruch um den letzten Befehl anzuschließen..
this.sendData("\r\n" + this._activeCmd.cmd + "\r");oder \r muss gegen \n getauscht werden.
\r ist Wagenrücklauf \n ist Zeilenvorschub. Unter Linux wird auf der shell ein \n gesendet. Der Pylontech hat gerne ein \r.
-
@plchome-0 habe gerade nochmal ins log geschaut:
pylontech.0 2024-02-21 12:42:30.168 silly bat 1 @ Battery Volt Tempr Base State Volt. State Curr. State Temp. State Coulomb 0 3361 19000 Charge Normal Normal Normal 60% 60896 mAH 1 3360 19000 Charge Normal Normal Normal 60% 60446 mAH 2 3362 19000 Charge Normal Normal Normal 60% 60841 mAH 3 3361 19000 Charge Normal Normal Normal 60% pylontech.0 2024-02-21 12:42:30.124 silly PYTES>i1 @ Unknown command 'i1' - try 'help' $$ PYTES> pylontech.0 2024-02-21 12:42:30.092 silly - - Absent - - - - - - - - - Command completed successfully $$ pylontech.0 2024-02-21 12:42:30.065 silly - - - - - - 14 - - - - - - - Absent - - - - - - - - - 15 - - - - - - - Absent - - - - - - - - - 16 - - - - - pylontech.0 2024-02-21 12:42:30.022 silly - 11 - - - - - - - Absent - - - - - - - - - 12 - - - - - - - Absent - - - - - - - - - 13 - - - - - - - Absent - - - pylontech.0 2024-02-21 12:42:29.979 silly - - - - - - Absent - - - - - - - - - 9 - - - - - - - Absent - - - - - - - - - 10 - - - - - - - Absent - - - - - - - - pylontech.0 2024-02-21 12:42:29.936 silly - - - - - - - - 6 - - - - - - - Absent - - - - - - - - - 7 - - - - - - - Absent - - - - - - - - - 8 - pylontech.0 2024-02-21 12:42:29.893 silly - - - - 3 - - - - - - - Absent - - - - - - - - - 4 - - - - - - - Absent - - - - - - - - - 5 - - - - - - - Absent - pylontech.0 2024-02-21 12:42:29.850 silly S>pwr @ Power Volt Curr Tempr Tlow Thigh Vlow Vhigh Base.St Volt.St Curr.St Temp.St Coulomb Time B.V.St B.T.St Barcode DevType 1 53780 529 24000 19000 19000 3359 3363 Charge Normal Normal Normal 60% 2024-02-21 19:39:27 Normal Normal ES1000626P010443 E-BOX-48100V-D 2 - - - - - - - Absent - - - - - pylontech.0 2024-02-21 12:42:29.807 silly @ Unknown command 'i' - try 'help' $$ PYTES> PYTE pylontech.0 2024-02-21 12:36:35.083 error Error: timeout pylontech.0 2024-02-21 12:36:30.112 silly PYTES>i pylontech.0 2024-02-21 12:36:30.080 silly - - - - Absent - - - - - - - - - Command completed successfully $$ pylontech.0 2024-02-21 12:36:30.048 silly - - - - - - - 14 - - - - - - - Absent - - - - - - - - - 15 - - - - - - - Absent - - - - - - - - - 16 - - - pylontech.0 2024-02-21 12:36:30.005 silly - - - 11 - - - - - - - Absent - - - - - - - - - 12 - - - - - - - Absent - - - - - - - - - 13 - - - - - - - Absent - - pylontech.0 2024-02-21 12:36:29.962 silly 8 - - - - - - - Absent - - - - - - - - - 9 - - - - - - - Absent - - - - - - - - - 10 - - - - - - - Absent - - - - - - pylontech.0 2024-02-21 12:36:29.919 silly Absent - - - - - - - - - 6 - - - - - - - Absent - - - - - - - - - 7 - - - - - - - Absent - - - - - - - - - pylontech.0 2024-02-21 12:36:29.876 silly - - - - 3 - - - - - - - Absent - - - - - - - - - 4 - - - - - - - Absent - - - - - - - - - 5 - - - - - - - pylontech.0 2024-02-21 12:36:29.833 silly PYTES> PYTES>pwr @ Power Volt Curr Tempr Tlow Thigh Vlow Vhigh Base.St Volt.St Curr.St Temp.St Coulomb Time B.V.St B.T.St Barcode DevType 1 53903 3338 24000 19000 19000 3367 3371 Charge Normal Normal Normal 60% 2024-02-21 19:33:27 Normal Normal ES1000626P010443 E-BOX-48100V-D 2 - - - - - - - Absent - - - - -den Aufruf 'i' bzw 'i1' gibt es nicht, wo kommt der her?
Heute Abend hab ich sicher mehr Zeit...
-
Da gibts nur das i von Info und die Nummer von den anderen Befehl. Das sieht mir aber nach eier Schnittstelle aus, die zeitweise abkackt oder NodeJs mach blödsinn
protected _getDataUS(option: any): Promise<any> { return new Promise<any>((resolve, reject) => { this._getUsPwr() .then((p: { pwrs: any; batteries: string[] }) => { this._getUsInfo(p, option.info, option.power) .then((p: resultForGet) => { this._getUsNormal(p, PWR, POWER, option.power) .then(p => { this._getUsNormal(p, STAT, STATISTIC, option.statistic) .then(p => { this._getUsBatterie(p, BAT, option.celldata) .then(p => { this._getUsBatterie(p, SOH, option.cellsoh) .then(p => { this._getOne(p.allData, LOG, LOG, option.log) .then(allData => { this._getOne(allData, TIME, TIME, option.time) .then(allData => { resolve(allData); }) .catch(reject); }) .catch(reject); }) .catch(reject); }) .catch(reject); }) .catch(reject); }) .catch(reject); }) .catch(reject); }) .catch(reject); }); } -
@plchome-0 Das fruchtet leider alles nicht. Zeit erhöhen macht keinen Unterschied und Zeilenabschluss mit \r und/oder \n in vielen Kombination, bringt auch keine Besserung. Hatte neben dem FTDI Adapter (vergossen mit Consolenanschluss auf RJ45) auch einen alten PL2303 versucht. Der scheint aber nicht wirklich gut zu laufen. Würde den USB/Serial Adapter gerne ausschließen, kannst du mir sagen welcher Adapter (vorzugweise über Amazon zu bekommen) gut funktioniert? Hab zwar noch ESP32/ESP8266 da, aber keine MAX Pegelwandler mehr.
Wie gesagt teilweise klappt die Abfrage mehrfach hintereinander und dann wieder timeout. Vielleicht ist die serielle Schnitstelle von der Pytes-V5 einfach eine Diva.
-
@bios123 Ich hab gerade den LogiLink AU0034 aus der Readme im einasatz, weil mir bei dem ESP die USB-Buchse zur Spannungsversorgung abgerissen ist und ich noch keine Zeit (oder Bock) hatte, den wieder zu reparieren
Ich habe aber auch keinen PI, sondern einen NUC im Einsatz. Ich gehe mal von einem PI als Hardware aus.
Zuerst solltest du mal im
dmesgschauen, ob die Schnittstelle Fehler meldet, wenn da irgendwas nicht stimmt, dann sieht man es da.Komisch ist ja, das es mit den Testscripts funktioniert und im Adapter Fehler produziert.
In der Debugausgabe, die Du gepostet hast, überholen sich auch die Meldungen. Das kann aber auch wegen Multitasking normal sein. -
@bios123 Du hast aber auch die Masse verbunden? Das fehlte mal eine Zeit in den Anleitungen.
DSUB signal
2 RxD
3 TxD
5 GroundAndere Seite in deinem Handbuch
-
@PLCHome-0 Die Schnittstelle habe schon kontrolliert,
dmesgzeigt da keine Aufälligkeiten: USB ran, wird erkannt und dann ist stille. Hab heute morgen einen Waveshare mit RS232/485/TTL geordert (den brauche ich noch für andere Projekt) und einen billigen USB Adapter mit Prolific Chipsatz, kommt morgen.
Wie gesagt iobroker läuft in einem LXC (Proxmox Host) und ttyUSB0 ist direkt durchgereicht. Den Aufbau hab ich mit verschiedenen USB Geräten am laufen da gibt es keine Probleme.
Wenn ich die Schnittstelle z.B. mit screen/dev/ttyUSB0 115200öffne, kann ich jeden Befehl ohne Probleme absetzen und sehe auch keine Übertragungsfehler. Die Befehlebat, info, pwr, soh, stat, time, verschließen direkt mit "Command completed successfully" ab:Command completed successfully $$ PYTES>Bei
helpundlogbraucht es ein Bestätigung der Abschnitte mit ENTERPYTES>log @ Index : 29 Time : 24-02-22 11:41:23 ModID : BMM Code : 1c5 Info : The device start charging. Index : 28 Time : 24-02-22 11:36:37 ModID : BMM Code : 1c4 Info : The device start charging. Index : 27 Time : 24-02-22 11:30:09 ModID : BMM Code : 1c3 Info : The device start charging. Press [Enter] to be continued,other key to exitIch hab jetzt keine tiefere Analyse gemacht: Wartet dein Code oder wertet er die Zeile aus? Welchen Indikator nimmst du um festzustellen das ein Abfrage fertig ist, also zB
info.Ich hoffe du hast noch ein wenig Geduld mit mir...
-
@bios123 sagte in Test Adapter Pylontech v0.0.8:
Ich hoffe du hast noch ein wenig Geduld mit mir...
Danke, dass du dir Gedanken machst. Aber einen Adapter, der nicht funktioniert, den braucht keiner
@bios123 sagte in Test Adapter Pylontech v0.0.8:
Welchen Indikator nimmst du um festzustellen das ein Abfrage fertig ist, also zB info.
while ((position = data.lastIndexOf('$$')) !== -1) { if ((start = data.lastIndexOf('>', position)) !== -1) { this.push(data.subarray(start, position - 1)); }Der Code wertet alles zwischen > und $$ aus.
if ((position = data.lastIndexOf('[Enter]')) !== -1) { data.write('-------', position); this.emit('needsenddata', '\r'); }Wenn er [Enter] empängt, ersetzt er es mit - und sendet ein \r, das wird für das Log benötigt.
Alles in ConsolenReader.ts zu finden.
--
Was ich komisch finde, ist das i1.
Was man im Log sieht, ist das echo. Das bedeutet, man sendet ein Zeichen an den Akku und dieser sendet es zurück.@Radi hatte auch ein Problem mit dem Kabel. @Radi, vielleicht kannst du noch mal bescheriben, was genau der Fehler war?
Da hat sich der Adapter doch auch total komisch verhalten. Es fehlten Zeichen und es waren welche da, die da nicht hingehörten.
-
@bios123 sagte in Test Adapter Pylontech v0.0.8:
Wie schnell rufst du die Daten ab? Eventuell braucht die Pytes V5 nach jeder Anfrage einen Moment.
Also wenn du eine Pause ausprobieren möchtest, dann kannst du folgende Zeile einfügen:
setTimeout(()=>{....},1000);**Editiert
1000 ist die Wartezeit in ms.
File
build/pylontech/WorkerAbstract.jsAlt:
_nextcommand() { debugApi("MyWorkerAbstract._nextcommand", "this._activeCmd:", this._activeCmd, "this._started:", this._started); if (!this._activeCmd && this._started) { this._activeCmd = this._commands.shift(); if (this._activeCmd) { this._parsers.setCMD(this._activeCmd.cmd); this.sendData(this._activeCmd.cmd + "\r"); this._activeCmd.timeout = setTimeout(this._ontimeout.bind(this), this._timeout); } } }Neu:
_nextcommand() { debugApi("MyWorkerAbstract._nextcommand", "this._activeCmd:", this._activeCmd, "this._started:", this._started); if (!this._activeCmd && this._started) { this._activeCmd = this._commands.shift(); if (this._activeCmd) { setTimeout(()=>{ this._parsers.setCMD(this._activeCmd.cmd); this.sendData(this._activeCmd.cmd + "\r"); this._activeCmd.timeout = setTimeout(this._ontimeout.bind(this), this._timeout); },1000); } } }**Editiert
Pass bitte auf das sich der Adapter nicht überholt. Das Abfrageintervall kann man in der Konfiguration einstellen. Aktuell hatte ich da nichts vorgesehen, da durch die Timeout der Abruf nicht länger als 1 Minute dauern konnte.
-
host.iobroker 2024-02-23 09:14:28.602 error Caught by controller[0]: SyntaxError: await is only valid in async functions and the top level bodies of modules host.iobroker 2024-02-23 09:14:28.602 error Caught by controller[0]: ^^^^^ host.iobroker 2024-02-23 09:14:28.602 error Caught by controller[0]: await new Promise((a)=>{setTimeout(a,1000)}); host.iobroker 2024-02-23 09:14:28.602 error Caught by controller[0]: /opt/iobroker/node_modules/iobroker.pylontech/build/pylontech/WorkerAbstract.js:72so leider nicht.
-
@bios123 sagte in Test Adapter Pylontech v0.0.8:
so leider nicht.
Ups sorry ich habs oben korrigiert
Ich sagte ja, eine Pause ist nicht so trivial.
-
@plchome-0 Kurzer Zwischenstand mit der Codeanpassung scheint es zu funktionieren. Ich lasse das mal so über Nacht laufen. Bin etxra auf 1 Minute Intervall runter und habe mich bei
setTimeout(()=>{....},100);auf 100 Millisekunden rangetastet. Sobald ich die anderen USB-Serial Wandler habe, wird aber nochmal ohne Pause getestet. -
@bios123 Kannst vielleicht auch mal mit 10ms probieren.
In 100ms kann die Schnittstelle schon 1152 Zeichen übertragen. Da könnte dir der Akku ja schon seine ganze Lebensgeschichte erzählen
115200 Baud 8n1 macht 1 Start + 8 Datenbit + kein Parity Bit + 1 Stop Bit, also 1+8+0+1 = 10 Bit für ein Zeichen, also 11520 Zeichen pro Sekunde im Maximum.
Ich gucke mir das mal an und werde die Wartezeit einmal pflegbar machen.
-
@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 beipwr, bat, log, infoundtime.Um wirklich sicher auszuschließen das es mit der Schnittstelle nix zu tun hat, habe ich kurzerhand
ser2netbemü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, statwaren immer inaktiv beim testen. Hier müsste fürstatja noch eine Anpassung rein das es die Abfragestat 1nicht gibt. -
@bios123 sagte in Test Adapter Pylontech v0.0.8:
soh, stat
Ja, die beiden gibt es so nicht, die solltest du ausschalten, damit es keine Irritationen gibt. stat unterscheidet sich auch zum Pylontech, da dort die stat pro Akku ausgegeben wird. Die Abfrage stat oder stat 1 sendet dort die Abfrage des ersten Akkus.
Aber eigentlich sollten diese Abfragen kein Problem darstellen, da sie mit > beginnen und mit $$ aufhören. Es finden sich nur keine Treffer mit den regex.
Das mit dem timeout ist irgendwie seltsam. Weil es zeitweise funktioniert und zeitweise nicht. Der Pylontch läuft mir ab und zu auch auf ein timeout so alle ein bis zwei Tage eine Abfrage. Ich dachte immer, es liegt bei mir am Wlan. Aber auch mit dem FTDI bekomme ich die Fehler auch alle ein bis zwei Tage mal.
Es kann natürlich sein, dass der Akku nicht gleichzeitig mit zwei Geräten kommunizieren möchte und die Konsole dann keine Antwort bekommt, wenn er gerade mit dem Inverter quasselt.
Ich muss mal schauen, ob es eine elegante Lösung gibt, im Falle eines Timeout das letzte Kommando zu wiederholen.
Und wie ich eine Verriegelung umsetzte, dass sich das Intervall nicht überholt.
Ich hätte allerdings nicht gedacht, dass es nicht dem nicht passenden Regex noch so viele Probleme gibt
