Rangliste

Hallo @meierchen006 , ich habe nichts in Frage gestellt, ich wollte nur meine Meinung zum Ausdruck bringen, und die ist nun mal so, das ich auf diese - zugegebenermaßen - doch etwas exotische Möglichkeit in einer Wallbox verzichten kann. Klar das Ding hat einen Rechner aber wo fängst du an und wo hörst du auf? Ich bin mir halt auch sicher das die Leute bei Tinkerforge bestimmt eine ganze Menge in der Pipeline haben, und nicht jedem Wunsch gleich hinterher rennen können. Ich finde die machen einen guten Job und reagieren echt fix auf Fragen der User. Vielleicht gibt es ja später - wenn die Batteriespeicher-Steuerung einmal fix und fertig bei den meisten Usern sauber läuft - auf diese Wünsche einzugehen. Letztendlich geht es ja in diesem Thread um das Testen dieser Steuerung (die prinzipielle Funktion mit verschiedenen Setups), der Rest kommt (vielleicht) später. Gruß Steffen

Glaubst du wirklich, dass a) das Balancing des BMS von BYD so grottich ist und b) eine Steuerung über eine Wallbox(!) der richtige Ansatz ist, dies in den Griff zu bekommen? Ich würde hier eher als Spielerei über z.B. Home Assistant Automationen ansetzen, wenn ich meinen würde, hier einen brauchbaren Hebel in der Hand zu haben.

Erzeugerwerte waren bei uns schon immer negativ. Wir richten uns da nach einem ISO-Standard für Energiezähler, der vorgibt, dass für Kraftwerk→Stromnetz→Endkunde positive Werte verwendet werden sollen und für Endkunde→Stromnetz dementsprechend negative Werte. Das wird meines Wissens auch von allen Energieversorger-Zählern so verwendet. Ein Zweitarif-Zähler zeigt bei Bezug üblicherweise „+A“ an und bei Einspeisung „-A“. Siehe dazu auch hier unter „Intelligente Stromzähler verstehen“ den Punkt 8 im rechten Bild. Dementsprechend ist bei uns sämtlicher Verbrauch positiv, inklusive einem ladenden Batteriespeicher, und sämtliche Erzeugung negativ, inklusive einem einspeisenden Batteriespeicher. Manche PV-Hersteller zeigen alles positiv an, vielleicht damit es besser in eine Grafik passt, und manch andere Hersteller drehen auch Einspeisung und Bezug um. Meine Vermutung wäre, dass positive Werte für Einspeisung einen „positiveren Eindruck“ beim PV-Anlagenbetreiber erwecken und deswegen marketingtechnisch besser sind. Oder die Hersteller kennen den ISO-Standard aus den 70ern, dessen Nummer ich auf die Schnelle nicht wiederfinde, einfach nicht.

Der Kollege ist noch nicht dazu gekommen die Email zu beantworten. Wir haben zwischen Weihnachten und Neujahr den Shop aktualisiert und auf ein neues ERP-System umgestellt, dadurch läuft noch nicht alles wieder mit 100%iger Effizienz :). Die Email ist auf jeden Fall angekommen.

Nachdem ich diesem Thread nun schon eine Weile folge, wollte ich auch meine Meinung dazu geben... Auch ich habe bei mir einen BYD-Speicher, der am Fronius Symo Gen24 hängt im Keller stehen. Ist das Balancing / BMS von BYD schlecht - keine Ahnung, da bin ich nicht wirklich im Thema. Ja, bei hoher Ladeleistung rennt die eine oder andere Zelle nach oben hin weg. Und ja ich kenne den Ellenlangen Thread im PV-Forum über das Laden der BYD-Akkus auch. Deshalb habe ich auch die Ladeleistung bei höherem SOC begrenzt - ob das wirklich zielführend ist sei mal dahingestellt. Das mache ich aber per Script im ioBroker, weil der eh im Keller vor sich hin werkelt. Ich finde aber, dass das (variable) Begrenzen der (Heimspeicher)-Ladeleistung (wie oben im Thread angesprochen) in einer Wallbox nichts zu suchen hat. Klar ein Entladen den Heimspeichers soll (sofern vom Nutzer gewünscht) verhindert werden. Die Wallbox soll schlicht und ergreifend das tun für was sie konzipiert ist, ein E-Auto Laden und das wenn möglich mit PV-Überschuss (sofern vorhanden) oder bei günstigem Strompreis - alles was darüber hinaus geht, gehört meiner Meinung nach in ein (übergeordnetes) System - ioB, HA, etc. Gruß Steffen

Hab gerade gesehen, dass ich die Frage noch nicht beantwortet hatte, bzw. teilweise ergibt sich die Antwort ja auch meinen vorigen Posts. Man könnte auf so eine Idee kommen, um einen kleinen Netzanschluss besser auslasten zu können: „Mein Staubsauger ist mein größter Verbraucher und zieht 6 A, also stelle ich das auf 6 A ein.“ Das würde im Normalfall wahrscheinlich sogar funktionierten. Aber dann kommt mal ein Handwerker vorbei, schließt seine 3,6 kW Hilti irgendwo an und noch bevor alle Löcher gebohrt sind, ist die Hauptsicherung raus. Steckdosen werden in Deutschland nun mal üblicherweise mit 16 A abgesichert. Dementsprechend muss man davon ausgehen, dass jederzeit mindestens 16 A zusätzlicher Verbrauch entstehen können. Deswegen erlauben wir es nicht, den Stromverbrauch des größten Einzelverbrauchers auf weniger als 16 A einzustellen. Da wir beim Netzanschluss mit einer kurzzeitig tolerierbaren Überlast von 40 % des Nennwerts rechnen, also 140 % Gesamtlast, ist das üblicherweise kein Problem.

Hier die extrahierten Stromverläufe. Die X-Achse sind Samples in Halbsekundenschritten. Ungefähr bei Sample 6300 wurde die 45 A-Überschreitung innerhalb weniger Sekunden beendet. Nachdem die anderen Verbraucher ausreichend lange ihren Bezug reduziert hatten, wurde die Ladung fortgesetzt. Ungefähr bei Sample 6150 sieht man eine kleine Stufe auf allen drei Phasen. Ich vermute, dass das der Zeitpunkt war, an dem die Ladeleistung auf 12,918 A reduziert wurde, was die Reaktion auf den seit Sample 6000 anhaltend hohen Strombezug war. Der Strombedarf des größten Einzelverbrauchers ist übrigens die größte tolerierbare erwartete Bezugsspitze. Die Absenkung des Ladestroms auf 12,918 A war dazu da, um genau die 16 A Reserve zu haben. In diesem Fall war die Spitze bei Sample 6300 ca. 12 A hoch. Da waren also noch 4 A plus Sicherheitsabstand Platz, bevor die Sicherung fliegen könnte. Wie du siehst, ist die von dir erwähnte kurzzeitige Überlastung bereits mit eingeplant. Bei uns wird nichts verschenkt. 😎 Ich würde sagen, das dynamische Lastmanagement hat exakt so reagiert, was es soll, und es wurde nicht unnötig oder zu früh abgeschaltet. Auffällig ist, dass L1 und L3 sehr dicht beieinander liegen. Anhand der L2-Kurve würde ich schätzen, dass da verschiedene Verbraucher abwechselnd und teilweise gleichzeitig aktiv waren. Anscheinend sind einige größere Verbraucher bei dir ungünstig auf L2 gehäuft. Was das ist, weiß ich natürlich nicht. Die Detektivarbeit überlasse ich dir. 😉

Die Ladung wurde durch das dynamische Lastmanagement beendet, da aufgrund von anderen Verbrauchern (Herd, etc) auf L2 nur noch 5,8 A verfügbar waren. Der minimale Ladestrom, den eine AC-Wallbox freigeben kann, liegt aber bei 6 A. Dementsprechend musste die Ladung beendet werden. In dieser Situation hätte dein Auto unter Umständen einphasig weiterladen können, da auf L1 und L3 noch Platz war. Dafür müsstest du aber die Phasenrotation deiner Wallbox angeben, also welche Phase der Wallbox mit welcher Phase vom Netzanschluss verbunden ist. Dazu kannst du unter Energiemanagement → Wallboxen den Eintrag für deine Wallbox editieren und die Rotation einstellen. L123 bedeutet, dass L1 der Wallbox mit L1 vom Netzanschluss verbunden ist und die anderen auch entsprechend. L231 bedeutet, dass L1 der Wallbox mit L2 vom Netzanschluss verbunden ist und die anderen entsprechend verschoben. Wenn du keine Ahnung hast, was die Rotation ist, kannst du unter Wallbox → Einstellungen → Zuleitung die Wallbox auf einphasig zwingen und einen Ladevorgang starten. Dann siehst du am Netzbezugszähler, welche Phase belastet ist. Die anderen beiden Phasen sind dann wahrscheinlich rechtsdrehend angeschlossen ist. Zieht das Auto einphasig am Netzanschluss auf L2 Strom, ist die Rotation entsprechend L231. Anschließend solltest du die Zuleitung wieder auf dreiphasig ändern. Du kannst die Einstellung der Zuleitung auch während eines Ladevorganges ändern und die Wallbox schaltet dann um, von drei- zu einphasig sofort, von ein- zu dreiphasig ggf. erst nach vier Minuten. Die Aufforderung zum Neustarten kannst du abbrechen. Für die Änderung der Rotation musst du allerdings neustarten. Ansonsten triffst du den Multicast-Bug in der aktuellen Firmware. Du kannst die Testfirmware von hier installieren.

Ich möchte Daten von meinem PC in einen MZ-80K Baujahr 1980 übertragen. Dafür habe ich mir eine Schnittstelle gelötet, die ich über ein IO16-v2 Bricklet ansteuere. Unter Visual Basic funktioniert das schon sehr gut, ich kann die Daten aus einer Datei in den MZ-80K übertragen. Diese Daten stammen aber eigentlich aus einer Excel-Tabelle. Anstatt diese Daten erst mal in eine Datei zu exportieren und diese dann mit Hilfe meines Übertragungsprogramms zu verarbeiten, müsste es doch eigentlich möglich sein, die Daten direkt mit Hilfe eines VBA-Makros zu übertragen. Das ist prinzipiell nichts neues für mich, ich habe bereits System-DLLs in VBA-Makros eingebunden und genutzt. Aber bei Tinkerforge kommen noch die Deklarationen hinzu, und da fehlen mir die Kenntnisse. Was mache ich mit folgenden Zeilen in Excel VBA? Imports Tinkerforge Public ipcon As New IPConnection Public io As New BrickletIO16V2()

Schön zu hören, dass es jetzt wieder funktioniert. Natürlich soll das nicht so sein, dass sich der NFC-Leser regelmäßig weghängt und vom Nutzer neugestartet werden muss. Falls das Problem immer wieder mal auftritt, achtet doch bitte darauf, ob ihr irgendwelche Gesetzesmäßigkeiten entdeckt, z.B. dass immer ein bestimmter Nutzer zuerst das Problem hat und dann andere Nutzer an der selben Wallbox auch Probleme haben. Es gab z.B. mal Probleme mit Smartphones. Ein Nutzer hatte seine NFC-Karte in seine Smartphone-Hülle gesteckt und hat somit Karte und Smartphone zusammen an die Wallbox gehalten, womit der NFC-Leser nicht zurecht kam. Das Smartphone-Problem sollte inzwischen behoben sein, aber vielleicht gibt es noch einen Sonderfall, der weiterhin nicht richtig funktioniert.

Ich habe die WARP auch noch recht neu. Bisher habe ich ein Widget in HA um ein paar grundlegende Infos zu sehen, den Lademodus zu wechseln oder den NFC Tag zu setzen. Die beiden letzten Punkte sind Custom Entitäten die ich per Node-Red erstellt habe. Node Red holt sich alle Infos aus der WARP config um es möglichst dynamisch zu halten. (Nutzer und zugehörige NFC Tags) Ich baue mir fürs Energiedashboard auch noch Entitäten die die geladene Energie pro Nutzer tracken. Die WARP gibt grundsätzlich ja die Energiemengen der Ladevorgänge aus inkl. user_id. Immer wenn sich der Wert erhöht addiere das der entsprechenden Entität hinzu. So habe ich quasi Stromzähler pro Nutzer. Ist für uns ganz interessant, da mein Auto ein Dienstwagen ist und der von der Frau privat.