Add note about silent devices (RS485)

[syssi]

Some soyosource inverters doesn't respond to the status request (0x24 0x00 0x00 0x00 0x00 0x00 0x00 0x00). The reason is unknown. There is a new hardware version since 2022 (purple mainboard / fw version STC8-2022-218) which probably doesn't respond to requests anymore.

The 2021 version (blue mainboard & green mainboard, fw version 2021-301) responds for some people and for some not.

[user0x01]

Ja, Das RS485 Interface vom Soyo ist auch etwas sensibel, das gute ist, es wird bei den neuen Soyos gar nicht gebraucht. Heute habe ich das Board mal gegen ein Optokoppler für Uarts getauscht https://www.ebay.de/itm/234384336691. Damit hat der Soyo dann gleich den Limiter erkannt.

Geantwortet hat er nicht. Wenn er nichts sagt, reicht es dann auch nur den TX vom ESP und RX vom Soyo mit einem passendem (nicht invertierenden, PNP) Optokoppler zu verbinden. Das hat den Vorteil, dass der 2 polige grüne Stecker dafür ausreicht. Da man im Eingang ja nur eine Leuchtdiode steuert. Ich denke, so was könnte passen. https://www.ebay.de/itm/401980747815

Da es einige Prüfungen in der Komponente gibt, die ohne die Statusabfrage nicht funktioniert, muss die Konfiguration zusammengestrichen werden, damit hat das Setzen der Leistung im Soyo dann funktioniert.

soyosource_inverter:

soyosource_virtual_meter:
  power_id: powermeter

  power_sensor_inactivity_timeout: 20s
  min_power_demand: 10
  max_power_demand: 900
  power_demand_divider: 1
  buffer: 10
  update_interval: 2s

sensor:
  - platform: soyosource_virtual_meter
    power_demand:
      name: "${name} power demand"

  - id: powermeter
    internal: true
    platform: mqtt_subscribe
    name: "${name} instantaneous power consumption"
    topic: "powermeter/sensor/metername/state"
    accuracy_decimals: 2
    unit_of_measurement: W
    device_class: power

binary_sensor:
text_sensor:
number:
switch:

[syssi]

Du warst beim Löschen der Sensoren sehr radikal. ;-) Versuch mal nur die Elemente zu löschen die zur platform: soyosource_inverter gehören. Bleiben sollten alle jene der platform: soyosource_virtual_limiter. Danach hast du wieder ein wenig mehr Bedienelemente und Sensorwerte, welche die Steuerung des Limiters betreffen. Die Plattform soyosource_inverter ist der Decoder der RS485-Antworten, welche es in deinem Fall nicht gibt. Deshalb gehört sie entfernt.

Meine Empfehlung ist, dass du dieses Setup auf deinem WiFi Dongle hinzufügst und für die Kommunikation mit dem Limiter-Port einen der unbenutzten GPIOs des ESP12e nutzt. Danach kannst sogar wieder den Betriebsmodus des Inverters durch den Limiter monitoren lasen. Wenn der Inverter nämlich in den Modus "Standby" fällt (z.B. wegen niedriger Batteriespannung) dann fährt auch der Limiter runter, weil er weiß, dass es nichts zu holen gibt.

Ich habe alle Komponenten so gebaut, dass sie nicht aufeinander angewiesen sind. Dein Ansatz war deshalb total richtig: Alle weg lassen, was in deinem Setup nicht funktionieren kann.

[user0x01]

Das Zusammenstreichen der Konfig war ein iterativer Vorgang. Alles, was das Setzen der Leistung verhindert wurde, entfernt. Am Ende war nicht mehr so viel übrig, dass ich dann die Minimalversion auf dem esp eingerichtet habe. Es bleibt dann nur die errechnete Leistung übrig. Der Status vom Limiter schlägt ja sofort im Limitersensor in Display an, wenn er aktiv oder inaktiv ist. Ich glaube, im Display ist alles drin, was ich vermisst hätte, wenn es nicht da wäre.

Ich hatte im Code nach der Meldung im Log gesucht ein gesehen, dass er durch Weglassen weiter kommt. Schön gemacht, man muss es nur wissen, dass es so einfach ist. Zuvor hatte ich versucht über lambda irgendwas zu setzen, hat zum Glück nicht funktioniert, ohne in den Quelltest zu sehen.

Für einfache kleine dinge, habe ich einige ESP8285 ESP-M3, die sind schon klein und lässt sich noch flashen ohne das ich, was dran löten muss. Für mehr Pins habe ich einige ESP8285 ESP-01M, die sind aber schon etwas dicht kontaktiert. Wahrscheinlich werde ich einen Sonoff Basic nehmen um den Inverter auch AC seitig ausschalten zu können, da fällt das TX dann mit ab.

[ehspill]

Moin,

bei mir will die 2021 (fw version 2021-301) ebenfalls keine Kommunukation. [15:45:42][W][soyosource_inverter:113]: 'balcony_inverter': The inverter didn't respond to the last 15 status requests

Mit https://github.com/KlausLi/Esp-Soyosource-Controller kann ich aber Werte auslesen und setzten, besteht die Möglichkeit das verhalten irgendwie zu debuggen, finde deine Integration besser.

[syssi]

@ehspill Wenn die Loesung von Klaus fuer dich funktioniert, sollte auch diese Implementierung Daten liefern, sobald sie korrekt verkabelt & konfiguriert ist. Hier findest du einen Abschnitt, wie man die uart-Komponente auf gesprächig stellt:

https://github.com/syssi/esphome-soyosource-gtn-virtual-meter#debugging

Daraufhin wird jedes ausgehende (>>>) und eingesehnde (<<<) Nachricht auf der seriellen Schnittstelle ins Logbuch geschrieben. Hier solltest du periodisch den Request an den Inverter sehen und simultan sollte die TX-LED auf deinem RS485-Wandler blinken. Ggf. ist hier bereits der Hund begraben und die GPIOs von TX & RX sind falsch gesetzt? Dann ist wichtig, was fuer einen RS485-Wandler du nutzt. Ist es die Variante mit oder ohne Flow Control Pin?

[ehspill]

Ich teste noch mal mit max debug output.

Der RS485 Wandler funktioniert, hängt ja so auch am Inverter mit der anderen Firmware.

Kann die Schweigsamkeit an nem "fehlenden" Hello bzw. fehlenden checksums liegen? Send in Hex : "24 00 00 00 00 00 00 00" 8 Bytes and then the soyo sends the status src: https://secondlifestorage.com/index.php?threads/limiter-inverter-with-rs485-load-setting.7631/post-78122

edit: sehe gerade in den debug logs das bereits 24:00... abgeschickt werden und keine Antwort vom Soyo kommt

[syssi]

Die Antwort auf die Flow Control Frage ist wichtig. ;-) Welchen Wandler betreibst du? Den oberen oder unteren: https://github.com/KlausLi/Esp-Soyosource-Controller/blob/main/BastelPlan0_ESP8266_Rs485_Modul.png

Besagte Nachricht wird periodisch gesendet:

https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/blob/main/components/soyosource_inverter/soyosource_inverter.cpp#L119 https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/blob/main/components/soyosource_modbus/soyosource_modbus.cpp#L126-L137

[ehspill]

Den oberen Wandler bzw.

[syssi]

In diesem Fall hätte es wirklich einfach funktionieren müssen. Das Standard-Update-Intervall ist 5 Sekunden. Du solltest deshalb alle 5 Sekunden die 24:00:00...-Nachricht sehen. Blinkt im gleichen Moment die TX-LED des Wandlers und wenn ja, blinkt kurz danach die RX-LED oder bleibt sie immer dunkel?

[syssi]

Bist du dir sicher, dass du mit Klaus-Lösung Daten empfangen kannst? Blinkt der sog. Herzschlag und siehst du Temperatur, Batteriespannung und Leistung?

[ehspill]

• Herzschlag - Ja
• Batteriewerte - Nein (Keine Batterie)
• Temperatur - gibt es nicht
• Leistung - Kann ich auslesen und setzen, wird gesteuert über ein Shelly 3EM.

Ich kabel morgen noch mal um und gucke ob der Soyo überhaupt irgendetwas antwortet.

[syssi]

Ich habe Zweifel, dass dein Soyo jemals geantwortet hat. Wuerde er antworten, so muesstest du mindestens eine Spannung in der DC-Zeile sehen, vorausgesetzt es liegt Spannung an: https://youtu.be/TAW5yowh12U?t=919

[ehspill]

Hm, Ja, guter Hinweis.

Ist bekannt warum manche Typen nicht antworten? Gibt es irgendwelche Logs die ich liefern könnte?

[syssi]

Nein. Es ist nichts bekannt. Es gibt leider das volle Spektrum an möglichen Ursachen:

1. Kontakte zwischen Mikrocontroller, RS485-Wandler im Soyo bis hin zur RS485-Buchse nicht sauber verbunden.
2. RS485-Wandler im Soyo von Haus aus defekt
3. RS485-Wandler in minderwertiger Ausführung (es gibt zwei Varianten)
4. Status-Antworten in der Soyo-Firmware deaktiviert, weil die Checksumme am Ende der Nachrichten schon immer kaputt war (über Inhalte gerechnet wurden die sich garnicht im Payload befinden). Anstatt die Checksummenberechnung zu fixen hat man sich vielleicht entschieden die Status-Nachricht zu deaktivieren.
5. Status-Request (24:00:...) wird nicht mehr akzeptiert, weil ein anderer Payload notwendig ist oder die Checksumme nun stimmen muss.

Was dein Soyo aber immer kann: Er ist nicht taub, sondern nur stumm. Schickst du eine Leistungsanforderung, so würde er dieser Aufforderung nachkommen.

[ehspill]

Moin,

Danke für die Info.

Mein Soyo nimmt ja die Leistungsdaten an, das funktioniert, wäre nur schön fürs Monitoring die anderen Daten ebenfalls zu haben.

Besteht die Möglichkeit das du einen reinen "Manual" Mode wie Klaus einbaust?

Also auch ohne Feedback vom Inverter Max Output setzen?

Ich wede meinen Soyo mal ausbauen und auf die Suche gehen, würde ggf. ein FW Dump helfen zur analyse?

Gruß

[syssi]

Es gibt einen manuellen Modus (Schalter+Schieberegler) wo du die Ausgangsleistung manuell setzen kannst. Ist das, was du suchst?

[syssi]

Ein Firmware-Dump wäre nett, obwohl meine Fähigkeiten beschränkt sind aus diesem Details zu extrahieren.

[ehspill]

Es gibt einen manuellen Modus (Schalter+Schieberegler) wo du die Ausgangsleistung manuell setzen kannst. Ist das, was du suchst?

Yes, wenn der Soyo nicht antwortet funktioniert das leider nicht, siehe unten.

[09:53:40][D][number:113]: New number value: 500.000000 [09:53:40][D][number:012]: 'soyosource-gtn-virtual-meter manual power demand': Sending state 500.000000 [09:53:41][C][soyosource_virtual_meter.number:041]: SoyosourceVirtualMeter Number 'soyosource-gtn-virtual-meter manual power demand'

[09:53:41][C][soyosource_virtual_meter.number:041]: Unit of Measurement: 'W' [09:53:41][D][soyosource_virtual_meter:060]: 'firstfloor_inverter': The operation mode of the inverter isn't 0x0 (normal). Suspending the limiter [09:53:42][D][soyosource_virtual_meter:072]: 'firstfloor_inverter': Setting the limiter to 0 watts per inverter (0 in total) [09:53:42][D][sensor:126]: 'soyosource-gtn-virtual-meter power demand': Sending state 0.00000 W with 0 decimals of accuracy [09:53:42][D][text_sensor:067]: 'soyosource-gtn-virtual-meter operation mode': Sending state 'Standby'

[syssi]

Entferne bitte diese Zeilen aus der Konfiguration, so dass der Betriebsmodus nicht laenger beachtet wird:

  # The operation_mode_id sensor is expected here. Passing the operation_mode won't work
  # The state is used to suspend the limiter if the operation mode of the inverter isn't 0x0 (normal)
  operation_mode_id: operation_mode_id

Klappt es dann?

[Chickenbreast0]

Hi Syssi,

ich habe ebenfalls eine 2021er Version mit der FW 2021-301. Der Soyo empfängt die eingestellten werde, harmoiert mit dem Shelly 3EM, aber gibt keine Werte, wie Spannung etc. aus.

Aktuell verwende ich den unteren Wandler, aber der obere kommt morgen rein. https://github.com/KlausLi/Esp-Soyosource-Controller/blob/main/BastelPlan0_ESP8266_Rs485_Modul.png

Hattest du mal versucht, das CPU Board oder die RS485 Platine zu wechseln, um den Soyo wieder gesprächig zu machen?

[syssi]

Hattest du mal versucht, das CPU Board

Habe ich noch nie versucht. Ich besitze 3 Modelle (2x mit Display & alt = gesprächig + 1x ohne Display = stumm).

oder die RS485 Platine zu wechseln, um den Soyo wieder gesprächig zu machen?

Bei einem der Display-Inverter ist mir die RS485-Platine abgeraucht. Diese habe ich aus Faulheit gegen einen teuren Ersatz vom Hersteller/Verkaeufer ersetzt. Dabei hat sich herausgestellt, dass es zwei Ausfuehrungen der RS485-Platinen gibt. Ich hatte damals Fotos der Platinen im Soyosource-Projekt von KlausLi gepostet. Leider sind hier die Issues mittlerweile geschlossen und die Fotos nicht mehr einsehbar. Die neue RS485-Platine sieht robuster aus.

Ich meine mich zu erinnern, dass Klaus die These aufgestellt hat, dass man jeden Soyosource gesprächig machen kann, wenn man lange genug an der Strecke zwischen Mikrocontroller und RS485-Buchse optimiert. Ich habe mich dem Thema aber nie angenommen, weil ich etwas Respekt vor möglichem Potential vor den Optokopplern habe. Ist man hier schmerzfrei, koennte man die RS485-Platine sogar entfernen und per UART-TTL direkt mit dem CPU-Board sprechen. Ich rechne aber damit, dass das CPU-Board es einem kurz oder mittlfristig übel nimmt. Ein ungefährliches Test-Setup könnte so aussehen:

CPU-Board RX/TX <---> ADUM1201 Optokoppler <---> ESP

Das normale Setup aus RS485-Konverter im Gehäuse und RS485-Konverter vor dem ESP ist nur nützlich, wenn man mit größeren Kabellängen arbeiten möchte.

Alternative Loesung: Ist meine Annahme richtig, dass dein Inverter ein Display besitzt? Dieses Display kann man abstecken. Auf dem Datenkabel des Displays fließen serielle Daten. Ich implementiere den Decoder aktuell hier:

https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/pull/104

Sollte man über den RS485-Port niemals an Daten bekommen, dann wird man es Notfalls immer über das Datenkabel des Displays schaffen.

[Chickenbreast0]

Danke für deine schnelle Antwort. Ja mein Soyo hat ein Display - ich hatte das Teil für 130 Flocken aus Vietnam (aus CN ;)) mitgenommen. Somit eine gute Sache. Das PCB Display ist blau mit dem Aufdruck V:3.03 und die RS485 Platine ist gleich der hier: https://de.aliexpress.com/item/1005003766395100.html

Das CPU Board sieht wie dieses aus: https://ae01.alicdn.com/kf/S26f66e59e2714cc78e7f9656c1ac6beay/EIN-Ersetzen-CPU-Board-f-r-SOYOSOURCE-1000W-1200W-Solar-Grid-Tie-Inverter-Ersetzen.jpgQ90.jpg.webp

Ich melde mich mit einem Log und Yaml Config morgen zurück, wenn der andere RS485 ankam.

By the way: Ich warte gespannt auf die Implementierung. Ich würde gerne einfach die Spannung etc. in HA einspielen können. Nur einen Shelly Plug S zu verwenden ist mir irgendwie "zu wenig" info :)

[syssi]

Dein Board ist das ordentlichere. Ich h abe die Fotos wiedergefunden:

[ehspill]

Das CPU Board hatte ich getauscht und untersucht, hat nix mit der externen Kommunikation geändert.

Ich würde eher auf das Board unterm display tippen. Der Soyo startet ja auch ohne CPU Board, ich habe leider keine Zeit mehr den Chip mit der FW zu suchen und zu dumpen.

edit: Hatte auch verschiedene RS485 wandler getestet ohne Erfolg.

[syssi]

Spannend. ;-) Dann kann ich noch ein Detail beitragen: Mein erster Soyosource wurde mit einer kaputten Display-Treiber-Platine (das Display war okay) geliefert. Man konnte trotzdem mit ihm kommunizieren (per RS485) und er haette auch grundsaetzlich funktioniert. Er war lediglich nicht bedienbar. Der Verkaeufer hat mir erst ein Ersatz-Display geschickt, welches mein Display-Problem nicht geloest hat. Nach dem Tausch der Display-Treiber-Platine war das Geraet dann bedienbar. Der Zaehlerstand (kWh) wird auf der Display-Treiber-Platine gespeichert und beginnt mit einer neuen Display-Treiber-Platine wieder bei 0. Ansonsten darf man sich die Treiber-Platine wie eine Fernbedienung mit Display vorstellen. Sie fragt periodisch Status-Informationen beim CPU-Board an und kann ein paar wenige Register aus der Ferne schreiben (Start/Stop-Spannungen, etc.).

[Chickenbreast0]

Success! Ich freue mich wie der Teufel :D Mit den RS485 Wandlern vom großen A click me bekomme ich sofort Werte in HA angezeigt.

Eingestellt sind manuell 50W in HA, aufm Soyo Display sind es 43-46W und über den Shelly Plug S ausgelesen 38,6 W. Bei 60W in HA sind es im Display 53W und im Plus S ca 48W. Auf jeden Fall sehr geil, dass es nun mit der Platine nun funktioniert..der Effizienz der Dinger bin ich mir bewusst :)

Der "Versuchsaufbau"..

[syssi]

Verstehe ich dich richtig: Dein Soyosource gehoert nicht zur stummen Sorte und antwortet nun auf Status-Requests?

[Chickenbreast0]

Verstehe ich dich richtig: Dein Soyosource gehoert nicht zur stummen Sorte und antwortet nun auf Status-Requests?

Absolut korrekt. Anbei das aktuelle Logfile. Wie man darin sieht, speist er nichts ein, da das Solarpanel noch mit einem Micro Inverter (Hoymiles) zuviel in die Leitung pusht. Ich hatte diesen kurz zum Test des Soyo abgeschaltet und entsprechend eingespeist. Falls du noch mehr logs benötigen solltest, dann lass es mich bitte wissen :)

logs_esphome-web-91fc6e_logs.txt

Mit dem og. Wandler funktioniert es einwandfrei. Anbei ein paar Hardware Impressionen:

[syssi]

Gut gemacht! :-) Das Setup läuft, wie es sich gehört.

[Chickenbreast0]

Gut gemacht! :-) Das Setup läuft, wie es sich gehört.

Ich danke dir vielmals für deinen schnellen Support. Fürs Protokoll, da ich nicht weiß wie es sich bei anderen Usern verhält: Das Delta zw. der Spannung, welche vom Inverter der Batterie ausgelesen wird und welche der EPEVER Laderegler misst, beträgt 0,5V. Sprich: Inverter misst 0,5V weniger als der Laderegler. Ich konnte dies mit zwei verschiedenen Multimetern nachstellen, dass die Werte des EPEVER stimmen.

[Chickenbreast0]

@syssi Eine Frage hätte ich noch - ggf etwas Off-Topic. Durch eine oder mehrere Änderungen mit Hilfe von Automatisierungen in Homeassistant betreffend des "max power demand" Wertes, ergeben sich dadurch Nachteile für die Speicherfunktion im Soyo? Sprich erhöhter Wearlevel?

Der Hintergrund ist, dass ich Automatisierungen verwenden möchte, welche den max power demand Wert nach Einspeiseleistung vom MPPT Regler regeln. (Der Soyo klemmt bei mir an zwei AGM Akkus und diese werden via EPEVER Regler geladen. Letzteren lese ich mit einem Elfin EW11 (Modbus) aus.)

[syssi]

Der max_power_demand-Wert wird einmal pro Minute im Flash/RTC des ESP8266 persistiert, sofern er sich geaendert hat und auf restore_value: true steht. Das Intervall lässt sich steuern:

preferences:
  flash_write_interval: 1min

https://esphome.io/components/esphome.html#adjusting-flash-writes

Wenn du den Wert sowieso taeglich x Mal neu setzt, dann wuerde ich restore_value auf false setzen und den Wert niemals im ESP persistieren. Stattdessen wuerde ich ein kluges Default im YAML unterbringen. Sollte der ESP mal neu starten, dann startet er halt mit diesem Default: initial_value: 600

[syssi]

Apropos Epever: Du koenntest auch einen zweiten RS485-Wandler nutzen und den Epever direkt vom ESP aus ansprechen: https://esphome.io/cookbook/tracer-an.html

[Chickenbreast0]

Apropos Epever: Du koenntest auch einen zweiten RS485-Wandler nutzen und den Epever direkt vom ESP aus ansprechen: https://esphome.io/cookbook/tracer-an.html

Ich beiß mir in den Hintern! Noch mehr zum basteln ;) Ansich könnte ich dem ESP die PINs D8 (GPIO15) und D7 (GPIO13) als TX und RX für den Epever abluchsen. Dabei hatte ich gerade so ein schönes Gehäuse für den 8266er gedruckt, welches aber wahrscheinlich zu klein werden wird. Ich sehe mich schon wieder die kommenden Tage neben dem Job als "busy" mit testen. Wenn alle Stricke reißen sollten, dann muss eben ein neues Gehäuse mit dem ESP32 her.

Ich war gerade noch dabei, die Antenne für ne Buchse zu modifizieren.

[syssi]

ESPHome hat ein nettes Feature beim ESP8266: Wenn man Pins nutzt, welche keinen Hardware UART besitzen, dann wird zur SoftwareSerial-Implementierung gegriffen. Du bist deshalb nicht auf 1-2 serielle Schnittstelle limitiert, sofern die Baudrate moeglichst niedrig ist. Die 4k8 für den Soyosource schafft ein ESP8266 locker per SoftwareSerial. Der Wechsel auf einen ESP32 mit 3 Hardware UARTS bietet sich also erst an, wenn du viele schnelle Geräte (JK-BMS mit 115k2) anbinden möchtest. Beim ESP32 ist man dann leider auf 3 UARTS beschränkt. Hier gibt es das SoftwareSerial-Feature bisher nicht.

[Chickenbreast0]

ESPHome hat ein nettes Feature beim ESP8266: Wenn man Pins nutzt, welche keinen Hardware UART besitzen, dann wird zur SoftwareSerial-Implementierung gegriffen. Du bist deshalb nicht auf 1-2 serielle Schnittstelle limitiert, sofern die Baudrate moeglichst niedrig ist. Die 4k8 für den Soyosource schafft ein ESP8266 locker per SoftwareSerial. Der Wechsel auf einen ESP32 mit 3 Hardware UARTS bietet sich also erst an, wenn du viele schnelle Geräte (JK-BMS mit 115k2) anbinden möchtest. Beim ESP32 ist man dann leider auf 3 UARTS beschränkt. Hier gibt es das SoftwareSerial-Feature bisher nicht.

Ich habe hier noch einen bzw. mehrere ESP32 liegen. Der EPEVER läuft nun soweit mit ein paar Anpassungen im Code auf folgenden Pins:

uart: id: mod_bus tx_pin: GPIO1 rx_pin: GPIO3 baud_rate: 115200 stop_bits: 1

Wie, und eventuell ist das eine absolute Newbie Frage, bekomme ich nun den Soyosource code von dir dort mit hinein? als TX2 ginge GPIO17 respektive RX2 auf GPIO16. Leider finde ich nichts passenden im Netz oder bin zu unbegabt. Herrje wird das hier Offtopic :D

[syssi]

Kannst du die beiden YAMLs zippen uns hier hochladen? Ich mache dir dann eine daraus. Danach hast du im besten Fall eine Idee, wie man es für gewöhnlich anstellt.

[Chickenbreast0]

Kannst du die beiden YAMLs zippen uns hier hochladen? Ich mache dir dann eine daraus. Danach hast du im besten Fall eine Idee, wie man es für gewöhnlich anstellt.

Sehr gerne :)

ESP32_8266_merge.zip

[syssi]

This is the combined (ESP32) version: epever-soyosource-combined.zip

You have to attach the RS485 converter of the Epever to GPIO1/GPIO3 and the RS485 converter of the Soyosource to GPIO16/GPIO16:

uart:
  - id: uart0
    tx_pin: GPIO1
    rx_pin: GPIO3
    baud_rate: 115200
    stop_bits: 1

  - id: uart1
    baud_rate: 4800
    tx_pin: GPIO16
    rx_pin: GPIO17

Thanks for your beer! ;-)

[Chickenbreast0]

This is the combined (ESP32) version: epever-soyosource-combined.zip

You have to attach the RS485 converter of the Epever to GPIO1/GPIO3 and the RS485 converter of the Soyosource to GPIO16/GPIO16:

uart:
  - id: uart0
    tx_pin: GPIO1
    rx_pin: GPIO3
    baud_rate: 115200
    stop_bits: 1

  - id: uart1
    baud_rate: 4800
    tx_pin: GPIO16
    rx_pin: GPIO17

Thanks for your beer! ;-)

You are welcome and many thanks for your support! Everything works as it should. :) Below the "proof" of my testing. The only thing I need to work on are those status messages, which occur as a number. But it should be easy to convert them as status messages instead. Further I am going to desgin a case for 3D printing, which both RS485 PCBs and generic ESP32 fits in.

[syssi]

The only thing I need to work on are those status messages, which occur as a number.

Could you tell me the entity you are talking about?

[Chickenbreast0]

I mean the "Charging Status" and the "Battery Status". If you could display the "Solar status" as well, that would be really great. Currently it just shows numbers like one, like in the screenshot above.

[Chickenbreast0]

I found a solution now.

I used the following code for it:

Currently I am facing another problem:

I am using a helper in Homeassitant to merge L1, L2 and L3 as a sum together. That one is just for the Soyo Suddenly the Soyo starts to oscillate without any reason and I can´t reproduce it.

• Restarting HA -> done.
• "soft" Restarting the Soyo with the emergency switch -> done.

Maybe you have a solution for it? Please find the current log as attachment.

logs_.zip

Update: After turning the fans on, by using the "Test menu" on the display and turning the device on and off on the AC side, it works again. Lets see tomorrow if I can reproduce the issue. The internal (read out) temp was around 40°C. Maybe that causes some that issue. I guess there is no possibility to control the fans by switching on and off. Too bad :(

[syssi]

Ich habe dir hier ein Beispiel gebaut, wie du die Werte in ESPHome decodierst. Ich hoffe das Beispiel funktioniert auf Anhieb: https://github.com/syssi/esphome-config-examples/commit/20cc3e259e32d0abf2a784ee9be3a0c8a6b30843

[Chickenbreast0]

Ich habe dir hier ein Beispiel gebaut, wie du die Werte in ESPHome decodierst. Ich hoffe das Beispiel funktioniert auf Anhieb: syssi/esphome-config-examples@20cc3e2

Danke... 2/3 der Veränderung funktionieren - der Charging Status leider nicht. Eventuell liegt an bei einem Fehler von mir.

-> current *.yaml current_yaml.zip

By the way...kannst du mir vielleicht sagen, wie ich den update_invertal für die Zeit verändern kann? Alle 30sec oder 60s würden ausreichen m. M. nach.

[syssi]

Deine Frage bezieht sich auf den Epever, richtig? In diesem Fall kannst du das Update-Intervall des modbus_controller anheben. Dann wird der Solarladeregler seltener gefragt:

modbus_controller:
  - id: epever
    address: 0x1
    modbus_id: modbus_epever
    command_throttle: 200ms
    setup_priority: -10
    update_interval: 30s

[Chickenbreast0]

I found a solution now.

I used the following code for it:

- platform: template
sensors:
epever_charging_status_text:
friendly_name: "EPEVER Charging Status Text"
value_template: >-
{% set mapper =  {
'1' : 'Not Charging',
'7' : 'Float Charging',
'11' : 'Boost Charging' } %}
{% set state =  states.sensor.esp32_epever_charger_status.state %}
{{ mapper[state] if state in mapper else 'Unknown' }}

> 
> Currently I am facing another problem:
> 
> I am using a helper in Homeassitant to merge L1, L2 and L3 as a sum together. That one is just for the Soyo Suddenly the Soyo starts to oscillate without any reason and I can´t reproduce it.
> 
> * Restarting HA -> done.
> * "soft" Restarting the Soyo with the emergency switch -> done.
> 
> Maybe you have a solution for it? Please find the current log as attachment.
> 
> [logs_.zip](https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/files/10991500/logs_.zip)
> 
> Update: After turning the fans on, by using the "Test menu" on the display and turning the device on and off on the AC side, it works again. Lets see tomorrow if I can reproduce the issue. The internal (read out) temp was around 40°C. Maybe that causes some that issue. I guess there is no possibility to control the fans by switching on and off. Too bad :(

**Update:**
Ich konnte den Fehler bisher doch nicht reproduzieren - dieser tritt unabhängig von der Temperatur auf. Gestern zw. 14-14:30 Uhr fing es damit an. Dann ein Soft-Aus nach 15:30 Uhr und vor 22 Uhr hatte ich den update_interval für das virtual meter auf 4s gesetzt. (Die ausgelesene Leistung erfolgt mit einem Shelly Plug S.)
![24h](https://user-images.githubusercontent.com/126453395/225838511-d9ec3e90-b646-4080-96c2-0f51817bef45.png)

Dann wurde die Regelung "unruhiger" und dann doch wieder nachts sehr auffällig.
![today](https://user-images.githubusercontent.com/126453395/225839371-c55f3481-ac3a-4780-ba32-2756db04b3ec.png)

Last but not least kappte ich komplett AC und DC Seite via Sicherung und seitdem regelt er wieder normal. Somit denke ich, dass es mit der DC Seite zu tun haben muss und sich irgendwas "verschluckt."
![4 Std](https://user-images.githubusercontent.com/126453395/225839387-4c14e02d-406b-44b3-b4e1-bffa84c21dbf.png)

[Chickenbreast0]

Deine Frage bezieht sich auf den Epever, richtig? In diesem Fall kannst du das Update-Intervall des modbus_controller anheben. Dann wird der Solarladeregler seltener gefragt:

modbus_controller:
  - id: epever
    address: 0x1
    modbus_id: modbus_epever
    command_throttle: 200ms
    setup_priority: -10
    update_interval: 30s

Genau..mir geht es um den Intervall der Zeit, nicht der Werte ;)

[syssi]

Lass uns bitte diesen Issue hier schließen und pro Thema einen neuen Issues aufmachen. Am liebsten wuerde ich hier sogar alle Off-Topic-Nachrichten entfernen.

[syssi]

Epever-Follow-Up: https://github.com/syssi/esphome-config-examples/issues/1