Modul PylonTech

[DS_Starter]

a- Fhem kann die Daten irgendwo an einem CAN Gateway abgreifen.

An der Stelle bin ich raus.

b- Obwohl für die 2/3000C Modelle angegeben ist, daß man bei RS485 keinen Hub braucht, könnte ich mit meine US5000 versuchen, die in 12er Gruppen aufzuteilen und am Hub den RS485 Modus zu fahren.

Damit wären wir weiter im Spiel.

[Janvi]

Auch nach Stunden bucht der LV-Hub noch einen der beiden Gruppen unerwartet aus wenn Fhem mitläuft bzw. ein Steuerpin unterbrochen ist. Wurde diesmal sogar an den Leds richtig angezeigt. Macht also auch keinerlei Sinn und ich habe wieder zurückgesteckt. Etwa die gleiche Beobachtung wie schon gestern nur etwas später. Möglicherweise werden zusätzlich zu CAN gelegentlich noch irgenwelche Steuerdaten über RS485 zwischen den Mastern übermittelt, was dann ein Schwebungsproblem mit Fhem ergibt bei welchem es dann irgendwann kracht. Schade, aber Pylons kommen eben aus China und da wird sich nix tun. Nach Zurückstecken des 1:1 Kabels hat es 3x gepiepst und der Hub hat selbstständig wieder auf 2 Gruppen umgeschaltet und weitergemacht.

Bleibt zu hoffen, daß die Pylons bei der Zellchemie nicht genauso gemurkst haben. So ganz wohl ist mir natürlich mir nicht solche Teile ins Zimmer zu stellen. Mein Kapazitätstest heute nacht war leicht über der erwarteten Berechnung. Alternativen (mit JK-BMS) gibt es wohl auch kaum da Pylon eine der am besten funktionierenden Batterien ist. JK-BMS kann das Pylon Protokoll emulieren, macht dabei aber auch Fehler wie Andy von der Off Grid Garage in einem seiner jüngsten Videos festgestellt hat.

[DS_Starter]

Hast du mal das neue Attr waitTimeBetweenRS485Cmd ausprobiert und auf >1s gestellt? Möglicherweise ist diese Pausezeit wichtig da sie explizit beim Multigruppenbetrieb erwähnt ist wie ich gelesen habe.

[Janvi]

Nein, ich habe deine neue Version noch nicht installiert. Ich weis auch nicht, wie der Multigruppenbetrieb auf RS485 funktionieren soll. Wenn der Hub als RS485 an den Master angebunden ist, kann nicht gleichzeitig auch noch ein Gateway die Request Telegramme losschicken. Beide Instanzen sind in keiner Weise synchronisiert. Solange die Inhalte der Request Telegramme gleich sind, merkt die Master Batterie nicht von wem die kommen. Aber es ist auch bei längeren Wartenzeiten zwischen den Telegrammen immer nur eine Frage der Zeit bis es kracht. Das liegt daran, daß das Protokoll ein Punkt zu Punkt Protokoll ist wo es keinen zweiten Master geben kann.

Man kann im RS485 Hub Betrieb also nur hören und sieht dann auch die Request Telegramme vom Hub inklusiv der darauf folgenden Antwort von der Batterie. Wenn der Hub aber nicht alles abfrägt - Pech für Fhem. Oder man schaut auf die typsichen Pausen zwischen den Abfragen des Hubs ob man zu einem unverdächtigen Zeitpunkt  zusätzlich eine eigene einschieben kann. Sauber ist das aber in keiner Weise und eine langsamere Abfrage macht nur die Wahrscheinlichkeit geringer bis es zu einer Kollision kommt.

[satprofi]

Frage, du benötigst den hub wegen can verbindung zum cerbo, oder?
Sonst könntest du mal nur rs485 ohne lv hub zu testen.

[Janvi]

Ja, aber ich glaube der Cerbo kann auch RS485. Nennt sich dort VE Bus. Hat ein eigenes Protokoll und ist zur
Verbindung der Multiplus untereinander bereits belegt. Darf man wohl auch nichts anderes dran machen.
Würde aber auch nichts helfen, ausser daß ich einen nutzlosen Hub übrig habe.
Denn auch dann wären zwei Instanzen welche eine Batterie auf der gleichen RS485 abfragen möchten.
Es geht bei euch nur deshalb, weil es zum Cerbo per CAN geht und Pylon die RS485 ausserdem nebenbei bedient.
Sobald ein Hub dabei ist, geht das nicht mehr, weil die RS485 mutmaßlich noch zu irgendwas zwischen den Gruppen missbraucht wird.
Wenn man das per Leitungsunterbrechnung unterbindet, geht es eine Zeit lang bis der Hub merkt daß was faul ist.
Entweder geht er dann ganz auf Fehler oder er bucht einen der beiden Gruppen aus. Nützt also nicht wirklich was.

[satprofi]

Nachfrage zu den 3 adern auf 0, hast du die auf ground gelegt oder nur getrennt? Was ich aus regelungstechnik kenne , ist 0 immer ground. Offen ist immer unbestimmter zustand.

[DS_Starter]

Ich könnte mir vorstellen, dass in solchen Fällen ein RS485 Splitter/Verteiler wie einer von denen helfen könnte um die Informationen der Batterie einmal zum LV-Hub und auch zum RS485 Gateway zu verteilen, bzw. andersherum die Befehle von beiden Quellen zur Batterie zu übertragen.
Aber nur Theorie ...

[Janvi]

Die Leitungen habe ich nur getrennt. Die Dioden gehen ja auch auf GND oder den ehemaligen GND. Vermutlich gibt es zu den Einängen irgendwo einen Pullup. Am Hub schreibt Pylon ja selbst vor, daß die pins 1-3 nicht verbunden sein dürfen. Als Nächstes wäre mal dran nachzugucken was sich auf den Signalen tatsächlich tut oder ob sie die ganze Zeit nur einen Pegel haben.  Eigentlich lohnt es aber nicht sowas verstehen zu wollen weil es klar ist, daß es kein sauberes Design ist. 

Die von @DS_Starter verlinkten Splitter sind HW Splitter für differentielle Signale. Die machen einen Sinn, wenn sich bei einem Bussystem mit mehreren Teilnehmern kein linearer Bus aufbauen lässt sondern eine Abzweigung benötigt wird. Die Abzweigung würde auf dem Signal Reflexionen erzeugen. Um die mit einem getrennten Widerstand terminieren zu können, nimmt man einen Splitter der mit einem Treiberbaustein elektrisch so tut, als ob die Leitung an der gesplitteten Stelle anfängt.

Auf der Protokollebene hilft das aber überhaupt nicht. Da geht es um Kollisionsvermeidung damit nicht 2 Teilnehmer gleichzeitig senden. Falls doch, muß dies erkannt und zur Korrektur wiederholt werden. Fehlerkorrektur ist schon an einer Punkt zu Punkt Verbindung nicht ganz trivial. Zum Beispiel das Protokoll von  Siemens RK3964 ist schon uralt und macht das ausserordentlich robust. Punkt zu Multipunkt, also ein Master mit mehreren Slaves ist etwas anspruchsvoller. Trotzdem gibt es genug freie Protokolle die das machen und an denen man sich orientieren kann bevor man meint etwas Eigenes erfinden zu müssen. Modbus RTP ist das bekannteste. CAN bietet gegenüber RS485 dann noch an wesentlichen Punkten eine Hardwareunterstützung welche die SW deutlich vereinfacht. Das sind HW Vergleicher welche auf die 11 oder 28 bit Identifier reagieren. Ein Teilnehmer kriegt dann nur noch die Telegramme mit, welche für ihn bestimmt sind. Auf RS485 müsste man hingegen alle eingehenden Telegramme auswerten und nachschauen ob der Inhalt die eigene Adresse betrifft. Es gibt auch Broadcasts welche alle Teilnehmer am Bus lesen können. Die Empfangsquittierungen gehen mit dem Acknowledge Slot per Hardware, so daß der Master automatisch mitkriegt, wenn der angesprochene Slave vom Bus entfernt wurde. Multimaster mit entsprechenden Verriegelungen und selbstadressierende Teilnehmer welche man nicht konfigurieren muß, Sicherheitsfeatures beim Ausfall eines Teilnehmers wurde alles schon mehrfach erfunden. Allerdings sind die Beschreibungen meist unter Verschluss. Für CanOpen muß man Mitglied beim CiA (Can in Automation) sein. Die NMEA2000 arbeitet mit den 29bit CAN Identifiern, ist im Bootsbereich für Kompass, Radar usw. weit verbreitet. Auch bei Victron gibts einen Treiber dafür. Die Spec dafür kostet zum Download aber schlappe 500 USD. Eine Zertifizierung von einem Produkt kostet dann noch extra bis man den Namen des Protokolls draufschreiben darf. Das alles nur um eine Kompabilität zu haben um jedem Käufer den Tausch mit einem Mitbewerber Produkt problemlos zu ermöglichen. Deshalb hält sich die Motivation für ein vernünftiges Protokoll bei vielen Herstellern in Grenzen.

Das mit der waitTimeBetweenRS485Cmd werde ich mal nachlesen und ausprobieren. Kann sein, daß sie damit etwas getrickst haben um Kollisionen zwischen zwei anfragenden Instanzen zu umgehen. Der Master wartet ob er in der Zeit jemand anderes hört. Falls ja, weis er daß er anschliessend diese Zeit hat um einen eigenen Request zu machen.






 

[satprofi]

Hallo.
Habe heute Modul upgedated, und jetzt keine Verbindung mehr zu Battery höher 8 . Was muss man jetzt neu definieren? group=0 hab ich dazu

LG

[DS_Starter]

Hi,

nichts. Es gibt in der Logik keine Einschränkungen außer bei der Definition.
Hoffe ich habe mich bei der Gruppenkalkulation mit Bat > 8 nicht vertan.
Verbose 5 des Devices mal checken.

LG

[e_brandt]

Hallo, ich wollte mal fragen ob ich das Modul auch über einen rs485 to Usb Adapter ansprechen kann oder ob ich zwingen einen wafeshare Adapter benötige?

Ich habe für einen sdm630 das modbus modul am laufen und dachte ich kann das alles zusammen auf diesem Wege einfangen.

[DS_Starter]

Hallo, ein Wafeshare muss es nicht sein, aber ein TCP/IP zu RS485 Adapter. D.h. USB Adapter gehen leider nicht.

[e_brandt]

Schade, ich habe einen USB Adapter im Betrieb an dem ich meinen Deye Wechselrichter auslese, wäre ja schön gewesen dort noch den Akku gleich mit anzuschließen.

[hauwech]

ich lese zur Zeit die Pylontech via Cerbo GX (Victron) mit MQTT aus.
Es fehlen allerdings die Werte für /History/DischargedEnergy bzw. /History/ChargedEnergy.

Ich habe seit Januar einen Victron MP + Pylontech US5000 + US3000 + RPi mit Venus OS am Start.
Die Batterien sind via CAN Bus Adapter am RPi angebunden und ich lese nicht via MQTT sondern Modbus aus ( da gibt es die beiden fehlenden Werte DischargedEnergy / ChargedEnergy.
Ich würde gerne mal deine Version testen, wie hast du die Pylontechs angebunden da in deinem Sreenshot eine IP steht. ( RS485 Adapter auf LAN ? )

Hallo WZut,
ich lese meinen Cerbo GX auch über Modbus, allerdings mit Loxone. Laut Victron sollte DischargedEnergy im Input Register Addr 301 und ChargedEnergy auf Addr 302 liegen. Da kommt aber bei mir nix, auch im ModbusDoctor nicht. Hast Du vielleicht andere Register gefunden, wo was drinsteht?

Gruß Roland