Im Discord Channel hat sich auch jemand die Arbeit gemacht [EDIT: @bennyb21 wars] aus den MQTT Nachrichten die Entitäten in HA anzulegen. Meine Version beinhaltet 2 Packs als Master und Slave benannt. Kann so in die configuration.yaml übernommen werden, sofern das Szenario passt.
Wenn man HA so konfiguriert, dass er automatisch alle Werte in die InfluxDB schreibt, hat Grafana darauf auch Zugriff. Man muss sich nur umgewöhnen die Einheiten, wie Watt oder Volt, zuerst auszuwählen, da HA alle Werte danach sortiert.
Das ist eine Sache, die ich wenn nur mal zu einem Test machen würde. Der große Vorteil und die initiale Idee hinter dem BSC war ja auch die galvanische Trennung der Komponenten. Damit in jeder Betriebssituation sichergestellt wird, dass sich Masseprobleme nicht durch die ganze Gerätelandschaft ziehen können. Man kann natürlich argumentieren das in Richtung Deye ja nur der CAN-Bus läuft, aber das ist halt eine Geschichte die man wissen und dann selbst bewerten sollte.
BT ist derzeit meine ich nur Testweise mit den JK implementiert. Und BT ist auch alles andere als stabil. Denke nicht das die Entwicklung groß in die Richtung weiter gehen wird.
Du hast deine BSC an dem Link Port (RS485) dran so wie hier zu sehen und kannst mit einem RS485 Adapter beide BMS auslesen. Das erscheint mir logisch, das lässt sich wahrscheinlich auch bis 15 Stück skalieren.
Was ich aber nicht verstehe, du hast auch noch den RS485/ETH Adapter für den Batterie Monitor am gleichen Strang hängen. Nach meinem Verständnis über RS485 (RTU) kann nur ein Master (BSC oder Batterie Monitor) auf die BMS zugreifen. Da sich sonst die Anfragen überschneiden und es zu TimeOuts führt. Ober gibt es eine Möglichkeit diese so zu tackten das die Abfragen nicht zur gleichen Zeit erfolgen?
Ja das geht bestimmt, übersteigt aber meine Fähigkeiten bei weitem. Muss warten bis das jemand mal umsetzt. Zudem bin ich einer der doch lieber auf Kabelverbindungen setzt (alte Schule ? )
Ich werde mir so einen BSC noch zulegen, doch aktuell scheint noch sehr viel Bewegung in der Hardware stattzufinden. Die Erweiterungskarte interessiert mich z.B. ebenfalls.
Genau so ist es. Wobei es sich aktuell nur bis 2 oder 3 funktioniert. In ein paar Monaten stocke ich die Packs nochmal auf und werde mit dem Entwickler des BSC sprechen.
[quote data-userid="11313" data-postid="128481"]
Was ich aber nicht verstehe, du hast auch noch den RS485/ETH Adapter für den Batterie Monitor am gleichen Strang hängen. Nach meinem Verständnis über RS485 (RTU) kann nur ein Master (BSC oder Batterie Monitor) auf die BMS zugreifen. Da sich sonst die Anfragen überschneiden und es zu TimeOuts führt. Ober gibt es eine Möglichkeit diese so zu tackten das die Abfragen nicht zur gleichen Zeit erfolgen? [/quote]
Es gibt Fehler wenn der BatteryMonitor gestartet ist, jedoch nehme ich das in Kauf, da ich nur sehr selten etwas über die Software anpasse. Man muss z.B. bei Änderungen von Parametern auch öfter auf speichern klicken um einen Moment zu erwischen, in dem der BSC nichts macht.
Ansonsten äußert sich das so, dass in regelmäßigen Abständen alle Werte im BatteryMonitor rot werden und in der nächsten Sekunde alles wieder ordnungsgemäß angezeigt wird.
Ich benötige eure Hilfe!
Das Auslesen des Deye mit einem ESP32 in Kombination mit einem RS485 funktioniert bei mir sehr gut.
Leider gibt es beim Auslesen der Adresse 667 (Wechselrichter am Generatorport) einen Datenfehler.
Sobald die Leistung auf unter 0 sinkt, und die Wechselrichter etwas Leistung abziehen, kommt auf der Adresse ein Messwert von über 65000 zurück.
Mein Gedanke ist jetzt, den falschen Wert beim einlesen der Parameter direkt "auszufiltern".
Leider sind meine YAML Kenntnisse nur rudimentär. Mein Ansatz sieht wie folgt aus:
deye12a sun12k-Generator Power sensor.deye12a_sun12k_generator_power
{% if states("sensor.deye12a_sun12k_generator_power")|float > 10000 %}
Setze sensor.deye12a_sun12k_generator_power auf 0
{%- else -%}
mache nichts
{%- endif %}
Die Auswahl über IF-ELSE funktioniert testweise.
Aber wie muss die Zeile "Setze" richtig aussehen?
Nicht wirklich zu gebrauchen fand ich, die Abfrageintervalle sind bei der Variante recht lang, da ist mir die esphome Anbindung über RS485 lieber. Alles was über den WLAN Stick geht, ist nur was zum Tageswerte sammeln interessant. Dann kannst auch gleich auf die Webseite vom Solarman schauen.
Aso verstehe. Hat sich die "klatremis" Version als aktuelle beste Variante herauskristalisiert?
Ich hätte schon auch mindestens gerne eine Steuerungsmöglichkeit der Time of Use aus Homeassistant. Möchte morgens den erwarteten Ertrag auswerten und den Akku dann entsprechend weniger stark laden, zB nur mit 0.1C wenn viel Sonne zu erwarten ist...
Es gibt nicht zufällig noch irgendwo eine Anleitung, wie ich das ganze dann genau in Homeassistant einbinde? Oder findet der das dann über Auto Discovery?
Bei der Aktivierung der MQTT-Integration wird auch schon der DEYE erkannt - es werden aber keine Sensordaten empfangen - nur eine entity mit dem Namen sensor.response.
