Habe es mal in ein Archiv gepackt, da sollte alles drin sein 
@Frozengun
Magst du mir mal als Screenshot zeigen, wie du das mit dem Cutter gelöst hast?
Ich betreibe meine Pylon’s seit über einem Jahr mit der RS232 Schnittstelle. Diese ist aber quälend langsam und scheint sich dann irgendwann auch zu verschlucken. Ich erinnere mich, dass ich damals auch an der RS485 diese Bruchstücke hatte.
Weiterhin würde mich noch interessieren, wie du das hardwaretechnisch gelöst hast. Hast du den RS484=>USB Konverter parallel auf den Bus gesetzt, der auch mit dem WR kommuniziert? Und wenn ja, welche Adresse hast du dem Konverter dann gegeben?
Gruß
Marc
Hmm, die RS232 läuft auch mit 111520 Baud, was soll da noch schneller ?
Selbst 2400 wären mehr als schnell genug, sind ja nur ein paar Bytes die da übertragen werden, und du wirst ja wohl nicht mehrmals pro Sekunde abfragen wollen.
Stabiliät: Ja, alle paar Monate mal hängt sie sich auf das stimmt. Die „C“ Version der Akku scheint mir empfindlicher. Nachm Firmware Upgrade war es dann deutlich besser. Hatte ich auf der RS485 aber auch schon da verlor der WR den Kontakt zum Akku.
Parallel mehrere Geräte an die RS485 klemmen wird wohl nicht gehen, entweder WR oder IPS.
mit sonnigen Grüßen
Bernhard
Welche Firmware hast du denn drauf?
VG,
Doc
Die „B“ weiß ich nicht, die haben aber von Anfang an gut funktioniert.
Dann hab ich „C“ nachbestellt und die kamen mit 1.7 glaub ich. Das war aber nix, gingen sehr oft auf Störung und machten jede Menge Zicken. Auch die Kommunikation war instabil.
Dann hab ich 2.1 raufgespielt und seit dem laufens stabiler aber noch nicht perfekt. Wie gesagt, alle 2-3 Monate etwa muß ich das Modul welches die Kommunikation macht neu starten.
Was bleibt ist das die „C“ offensichtlich einen höheren Innenwiderstand haben als die „B“.
d.h. in der Parallelschaltung haben die „B“ dadurch einen höheren kW Durchsatz als die „C“.
Die COP Kurven bzw. Stromkurven der beiden Gruppen sind deutlich unterschiedlich.
Alles in allem trotzdem eine feine Sache. Jetzt müssens nur noch die Lebensdauerversprechungen beweisen.
schöne Grüße
bb
Ich habe insgesamt 8 Batteriemodule. Die werden zyklisch abgefragt. So komme ich quasi alle 10 Sekunden an aktuelle Werte. Ich hatte da vielleicht auch mehr erwartet. Mir geht es vor allem um den Batteriestrom. Was die Übertragungsrate (Baud) betrifft. Macht es in der Tat keinen Unterschied, wie hoch die eingestellt wird.
Nachdem ich die letzten drei Module aus der B-Serie nachgerüstet habe, musste ich ebenfalls feststellen, dass diese offensichtlich einen etwas höheren Innenwiderstand haben. Das fing also schon vor der C-Serie an.
Beste Grüße
Marc
Hallo Marc,
anbei der Screenshot mit dem Cutter:
Rein vom Datenfluss sieht es dann so aus:
RS485>RS485toUSB>Symcon Serial Port>Cutter>Splitter
Ich kommuniziere mit dem WR über CAN, deshalb kann ich relativ einfach über den RS485 Bus arbeiten. Also falls es irgendwie möglich ist, auf CAN setzen (bei mir mit einem Growatt WR). Für die RS485 Verbindung, nutze ich den Waveshare Industrial USB to RS485 Converter.
Ich habe das Modul etwas modifiziert. Ich habe die Sleep Zeit zwischen den Abfragen von 2s auf 400ms reduziert und den Aktualisierungsintervall vom Stack auf ms konfiguriert. So bekomme ich effektiv Daten bis auf 1-2s wenn gewünscht. Ob das jetzt auch mit RS-232 möglich ist, müsste man testen. Meine C Version, bietet das glaube ich nicht mehr an.
Gruß Sebastian
Nur interessehalber: Für was benötigst du die Daten mit einer derart geringer Auflösung ?
Da ist doch eh alles sehr träge. Hab jetzt hier 1min, aber 5min wären auch genug.
fragt sich
bb
Die Daten wie Zellspannung oder SOC sind in der Tat eher träge. Mir geht es aber wie froema eher um die Ströme. Durch die PV Geschichte und Verbraucher sind diese schon sehr wechselhaft. Da ich den WR im 5s polle, wäre es nicht so schön, wenn die Ströme/Leistungen dann eingefroren sind und nicht zu den anderen Werten passen.
Kannst du hier auch kurz angeben,
welche Stellen vom Modul du wie modifiziert hast?
Würde das gerne mal testen.
VG,
Doc
Ja, das interessiert mich auch. 
So, nun auch die Erklärung dazu. Bis jetzt messe ich den Batteriestrom über einen Shunt. Dahinter sitzt ein Messwandler und dann geht das in meine Siemens Logo. Ich brauche die Ströme, da ich den Solarüberschuss zusätzlich nutze und mit einem separatem Ladegerät in die Pylonen jage. Ich setze auf möglichst viel Autarkie. Da mein WR nicht so große Ladeströme kann nutze ich jedes bisschen Leistung, Um sie selber zu nutzen, als ins Netz zu speisen. Da darf man gerne geteilter Meinung sein, aber ich mache das so. Wenn jetzt aber ein Verbraucher wie eine Wasch- oder Spülmaschine ins Rennen geht, möchte ich das halbwegs in Echtzeit mitbekommen. Das geht über den Ladestrom der Batterien am Besten, da der WR ja an der Energiemessung hängt.
Ich habe auch noch eine Zusatzbatterie aus einer alten Notlichtverteilung, die spielt da auch noch mit rein. Ist alles total bekloppt, macht aber Spaß.
Gruß
Marc
Hier mal ein paar Screenshots, ich denke so ist es am einfachsten:
IPSPylontech:
IPSPylonstack:
Ist nichts besonderes, aber hilft das Modul etwas zu beschleunigen. Die Aktualisierungszeiten von den Modulen selbst, habe ich auf 0 gestellt.
Gruß Sebastian
@Frozengun
Hallo Sebastian,
vielen Dank für die kurze Anleitung mit den Screenshots. Ich hatte an einer der Stellen auch schon geschraubt, aber mir kam nicht der zündende Funke. Nun habe ich Aktualisierungszeiten für alle 8 Module von 4 Sekunden. Das ist ja schon zig mal besser als vorher.
Gruß
Marc
Wie bekommst du denn die Daten so häufig?
Wenn ich im Pylonstack den Intervall auf 4000ms stelle bekomme ich trotzdem die Daten schnellstens nur alle 30 Sekunden?
Wo finde ich diese 400ms denn?
Ich hatte gedacht, das waren die Änderungen die er obern als Bild gepostet hatte?
Die 400ms sind einmal im Modul selbst und einmal im Pylontech Stack einzutragen. Wichtig war bei mir allerdings auch, bei den einzelnen Modulen, die Zeit auf 0 zu nehmen. Ehrlich gesagt weiß ich auch gar nicht, warum es im Stack eine gibt und in den Modulen, weil das Stack eigentlich alle Module abfragt 
Meinst du jetzt in der Instanz oder im Script selber?
Ich habe nur ein sleep(2); im PylonStack gefunden, welches in den Modulen selber meinst du denn?
