Test Adapter Pylontech v0.0.10

[bios123]

@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.

[PLCHome 0]

@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 dmesg schauen, 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.

[PLCHome 0]

@bios123 Du hast aber auch die Masse verbunden? Das fehlte mal eine Zeit in den Anleitungen.

DSUB signal
2 RxD
3 TxD
5 Ground

Andere Seite in deinem Handbuch

[bios123]

@PLCHome-0 Die Schnittstelle habe schon kontrolliert, dmesg zeigt 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 Befehle bat, info, pwr, soh, stat, time, ver schließen direkt mit "Command completed successfully" ab:

Command completed successfully
$$
PYTES>

Bei help undlog braucht es ein Bestätigung der Abschnitte mit ENTER

PYTES>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 exit

Ich 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...

[PLCHome 0]

@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.

[PLCHome 0]

@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.js

Alt:

  _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.

[bios123]

@plchome-0

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:72

so leider nicht.

[PLCHome 0]

@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.

[bios123]

@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.

[PLCHome 0]

@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.

[bios123]

@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.

[PLCHome 0]

@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

[bios123]

@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]

@bios123 sagte in Test Adapter Pylontech v0.0.8:

Muss ich mal beobachten ob das nur bei 100% auftritt (habe den Fall mit fetchCmdSerial.js gesichert):

Wird wohl da da sonst nicht 100000mAh stehen. Bei 99% sind im Accu 99000mAh, dann passt der RegEx.

/build/pylontech/ParserUSBatN.js

aus

const rowB = /^(.{9})(.{9})(.{9})(.{13})(.{13})(.{13})(.{13})(.{10})(.{9,16})?(.{1,3})?/gm;

wird

const rowB = /^(.{9})(.{9})(.{9})(.{13})(.{13})(.{13})(.{13})(.{9})(.{10,17})?(.{1,3})?/gm;

Ja, das ist dann ein String weil "100% 1" nicht als Zahl erkannt wird.

[bios123]

@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]

@bios123 Ok, das ist ein Problem. Der Adapter hat wie auch in den Beispieldaten 0x0 gefunden. Das ist eine Hexadezimale 0. darus macht er eien Dezimale 0.
Weil er 0x<ziffern sieht>. Nun sieht er 0x<ziffern sieht> <text> und wandelt es in Text.

[PLCHome 0]

@plchome-0 ich mache gleich mal eine 0.0.10 die sollte das dann können

[derAuge]

@l1berty
Den Waveshare RS232/485/422 to RJ45 Ethernet Module, TCP/IP to Serial habe ich mir gerade bestellt.

nun fertige ich gerade das Anschlusskabel.

Pin1
Pin2
Pin3 => 232TX
Pin4
Pin5
Pin6 => 232RX
Pin7
Pin8 => GND

Pin2 => RXD
Pin3 => TXD
Pin5 => GND

Frage: Müssen die Anschlüsse gekreuzt werden? (232TX-RXD) (232RX-TXD) (GND-GND)
Oder eine 1:1 Verbindung?

Wenn die Lieferung am Montag kommt, kann ich mit dem Testen unterstützen.
Es sollen 4x UC3000 ausgelesen werden

Gruß
Jürgen

[PLCHome 0]

@derauge
Das Bild findest du zusammen mit dem Pinout in der readme.

Die Geräte haben einen Stecker, daher muss es an der Kupplung so wie in der Readme angeschlossen werden.
Bei Kupplungen an den Geräten und Steckern am Kabel müssen RX und TX getaucht werden.

US3000 sollten einwandfrei funktionieren. Bitte nur den Ersten im Stack auslesen.

[derAuge]

@plchome-0

super,
habe nun ein Kabel angefertigt.
Wie kann ich es testen?
Habe einen Digitus USB-RS232-Adapter und ein Terminalprogramm.
mit welcher Baud-Rate und mit welchem Befehl kann ich etwas aus der Konsole locken?

Gruß
Jürgen