Solar EPEVER EPSOLAR u.ä. [98_ModbusEPEVER] [98_ModbusUPOWER] [98_ModbusIPOWER]

[laserrichi]

ok dann zur Kür

mir ist aufgefallen das ich da noch 2 Baustellen hatte die noch garnicht angegangen wurden, und zwar B18 ElectricChrgState  und B36 LoadOutputState

da hatte ich die ganzen Fehlerbits und auch welcher Ladestatus gerade ist noch nicht umgesetz.

Das ist ja eigentlich das interessante
Da es jeweils ein Reading ist wird dann der entsprechende Text ausgegeben.

[kurt6908]

Hallo laserrichi,

ich hab das Modul aktualisert, aktuell werden folgende Werte bei den neuen Readings angezeigt:

ElectricChrgState   
Normal StandbyNo charging Input Voltage Normal OutputPower: Light load

LoadOutputState   
Normal StandbyInput Voltage Normal OutputPower: Light load

Die Werte sind plausibel. Aber vielleicht könnte man im Reading die einzelnen Werte durch Kommata trennen, dann könnte man sie leichter danach über eigene Routinen zerlegen. Gleiches auch bei BatteryState, PvChrgStat.

Viele Grüße

Kurt

[laserrichi]

habs eingecheckt auf 1 Beitrag

Wenn diese readings:
ElectricChrgState LoadOutputState BatteryState PvChrgStat   
jemals Fehler ausspucken sollten, dann sind die Readings viel länger um die entsprechenden Texte, diese hab ich mal am Anfang eingefügt.
Da diese Register ja mal mehr und mal weniger liefern , kann man jetzt auch nicht sagen ab Pos. 2 ist immer der Wert.

Die Auflösung der bits mache ich in subrutinen und man kann die Werte bei den returns auch anders sortieren (zeilen 565,602,640,666)

[fritzhugo123]

Hallo zusammen,

ich habe meine Anlage um zwei Laderegler von Toyo erweitert und möchte diese nun auch in FHEM einbinden.
Die Kommunikation läuft auch über MODBUS, aber die Werte scheinen andere zu sein.
Eine Verbindung zum Laderegler konnte ich erfolgreich herstellen, aber ich bekomme keine Reading bzw. sind diese leer.

Folgenden Link habe ich für die Dokumentation der Werte gefunden.
https://github.com/logreposit/renogy-rover-reader-service/blob/develop/doc/rover_modbus.pdf
Die Frage ist, ob es möglich ist diese anzupassen oder ein neues Modul für Toyo zu schreiben?
Die Laderegler von Renogy scheinen wohl auch kompatibel zu Toyo zu sein.

Gruß, Matthias

[uli-bs]

@laserrichi
Zunächst Danke für das Modul, funktioniert im Testbetrieb, mit meinem neuen EPEVER 2210AN einwandfrei.
Konfiguration über RS485/TTL Modul, Pegelwandler und ESP8266 mit aktuellem esp-easy als seriellem Server

Weil das so gut funktioniert, bringt mich das aber auf Ideen... 

Ich habe auch noch einen Wechselrichter von Huayu, der hat eingebautes WLan und proprietäres Zigbee.
Über das WLan ist eine rudimentäre Weboberfläche erreichbar und es werden umfangreiche Daten in die Cloud von SOLARMAN übertragen (wie bei fast allen Wechselrichtern, die intern mit Hardware von Deye bestückt sind (z.B. Huayu, Bosswerk, sun-solar,...)).
Diese Übertragung passiert ebenfalls im Modbus Protokoll (v4 bzw. v5) auf Port 8899 (siehe dazu https://forum.fhem.de/index.php/topic,123506.msg1233005.html#msg1233005)

Ich habe testweise mal IP und Port des WR im DEF für dein Modul eingetragen und bekomme zwar keine Daten (was auch nicht zu erwarten war) aber immerhin ein "online".
Wenn Du also mal Lust und Zeit hast, da mal einen Blick drauf zu verschwenden, wäre sicher nicht nur ich dir sehr dankbar.

VG
Uli

[laserrichi]

Sorry ich habe da leider keine Zeitliche Resource frei für weitere Module... kämpfe mit meinen eigenen dingen

Wichtig ist hier grundsätzlich DOKU vom Hersteller und das diese auch vollständig und richtig ist.

alles hier basiert ja auf Stefan Strobels seinen Modul und mit ModbusAttr kann man alle register als attr einbauen. Dann kann man diese als eigens Modul auch Speichern und auch mit subroutinen behandeln.

Auch wenn sich Geräte äußerich ähneln, gibt es doch gerade in der Software massive unterschiede.

[VB90]

Fürs Protokoll:

Herzlichen Dank für das Modul!!

Mit Hilfe dessen habe ich inzwischen 4 Epever Tracer in einer Anlage in Betrieb genommen.

Funktioniert tadellos.

Danke,

vb

[Jarnsen]

Hallo, ne Frage, könnt ihr mir sagen welches Register für Fehler löschen zuständig ist? Am Epever bestätigt man ja mit der ENTER Taste und am MT50 auch.

[laserrichi]

Hallo, ne Frage, könnt ihr mir sagen welches Register für Fehler löschen zuständig ist? Am Epever bestätigt man ja mit der ENTER Taste und am MT50 auch.

weis nicht welchen du da hast, aber wenn du die enter drückst, dann schaltest du normal damit nur die Last ein und aus.
Fehler kann man nicht zurücksetzen. Das sind nur Statusbits die der Laderegler liefert.
Bei Kurzschluss schaltet er die Last z.b. ab. Wenn du dann Enter drückst, schaltest du die einfach wieder ein.

Zurücksetzen kann man bei manchen die Energiezähler oder auf Default werte.

[horni]

Bin ich eigentlich der einzige der da ab und zu extreme Fehlübertragung hat mit dem Epever?

Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.

Was habe ich schon alles ausprobiert um den Fehler zu beheben..

- Baudrate von beiden Epever auf 56200. Keine Besserung
- Level-Shifter auf RXD eingebaut. Keine Besserung
- Anderen ESp8266 genommen. Auch keine Besserung
- Software von ESP-Link auf ESPEasy geändert. (Auch verschiedene Ports ausprobiert) Auch keine Besserung
- Kabel alle getauscht. Keine Besserung
- 120 Ohm Abschlusswiederstand eingelötet. Keine Besserung
- Einzelnen Epever angeschlossen. Auch keine Besserung
- ESp8266 an einer anderen 5 Volt Stromquelle angeschlossen auch keine Besserung

Das ganze seltsame ist, wo ich Epever Kontroller von KlausLi genommen habe und das über ein Jahr lief hatte ich nicht einmal einen falschen Wert bekommen.  Könnte es sein das hier keine CRC Überprüfung stattfindet ? Das ist halt echt blöd weil er mir dann jedes mal die Statistik total versaut
 

[laserrichi]

Du schreibst "beide EPEVER"

d.h. du hast 2 am gleichen Bus ?
Dann musst du über ModbusProxy gehen.
Oder hat hier jeder seinen eigenen Esp ?

[horni]

Ja einen 10 Ampere und einen 20 Ampere Epever. Aber die ID ist bei beiden geändert. Der eine hat die 1 und der andere die 2. Das alles spielt aber keine Rolle da ich es mit einem auch schon probiert habe und da genau den selben Fehler habe.
Kann man ja auch wunderschön beim definieren angeben mit der ID mit
define Epever1 ModbusEPEVER ID Zeit IP Protokoll
Klappt ja auch nur halt mit Fehlübertragungen hin und wieder. Jetzt wollte ich halt bloß wissen ob auch jemand das hat oder nicht
Habe jetzt mal noch spaßhalber es auf einen Esp32 angeschlossen. Ist noch katastrophaler ( Um 20:30 Uhr wieder zurück gemacht auf ESP8266)

Du darfst diesen Dateianhang nicht ansehen.

[laserrichi]

nochmal anders ausgedrückt, wenn du 2 devices auch mit unterschiedlicher ID hast gibt es kollisionen da der espeasy usw. nur 1 Verbindung aufrecht erhalten kann.

Daher im Fhem ein Device für die Kommunikation und dann die logischen devices darüber:

siehe: https://forum.fhem.de/index.php?topic=75638.937

In deinem Fall
Interface:
define ModbusProxy Modbus <ip-adress>:23
epever1:
define  epever1 ModbusEPEVER 1 60 RTU
epever2:
define epever2 ModbusEPEVER 2 60 RTU

PS: du musst auch auf die baudraten achten das die alle gleich sind. Hast vermutlich schon. Und ganz wichtig.... keine logs auf die serielle.... im espeasy auschalten.

[horni]

Wenn ich das so mache wie du schreibst dann kommen keine Daten bei den einzelnen Epever rein. Kann dann auch mit Get keine Daten lesen. Also ESP-Link ist zur Zeit aktiv bei mir.
So habe jetzt mal 2 ESp8266 genommen. Also jetzt hat jeder Laderegler seinen eigenen. Mal schauen was passiert.

[laserrichi]

Also das device modbusproxy quasi, hat das den status open angezeigt ?

Bei den devices sollte dann bei den internal reading auch IODev  modbusproxy stehen  oder wie auch immer das du dann benannt hast.

man kann vielleicht bei den devices auch das IODev angeben.
Ich habs bei mir nicht gemacht und geht trotzdem.
Wie sieht dein list der devices aus ?

Mit ESP-link hatte ich damals auch Probleme,  mitlerweile sollte das aber auch funkionieren.
Da hab ich auf den Reglern und im ESPEasy 115200 als Baudrate fest eingestellt und 8N1.