PV-Überschuss laden mit ABL eMH1?

[Carolus]

Hallo Matty67,

vielen Dank für Deine Antwort und die ausführliche Beschreibung Deines Equipments. Es sind tatsächlich zwei USB-RS485-Adapter mit einem Kabel verbunden, um den Bus zu simulieren.
Es ist wirklich eine sehr gute Idee, das Ganze per WLAN zu betreiben, so dass die ganze Verkabelung entfallen kann.

Der RS485-Bus kann ja nur im Halb.Duplex-Modus betrieben werden (entweder senden oder empfangen). Es gibt aber noch die Möglichkeit, den Receiver auf der Senderseite ständig aktiv geschaltet zu lassen, so dass jedes Zeichen, das verschickt wird, auch sofort wieder auf der Senderseite empfangen wird.

Auf dem RS485-Bus sieht man davon natürlich nichts, da sich das Ganze im Innern des USB-RS485-Adapter abspielt.
Damit kann der ordnungsgemäße Versand einer Nachricht kontrolliert werden und potentielle Bus-Kollisionen erkannt werden.

Da ich dieses Feature bei meinem FTDI-USB-RS485-Adapter aber nicht habe (ich weiß nicht wie ich es aktivieren kann) wäre es evtl. möglich, dass das der Grund ist, warum das ABL-Konfigurationstool meine Antwort-Telegramme nicht akzeptieren möchte, weil das Echo der vom Tool versendeten Nachrichten nicht
bei ihm ankommt.
Was gegen diesen Verdacht spricht sind Deine (guten) Erfahrungen mit ganz gewöhnlichen RS485-Adaptern.

Vielen herzlichen Dank nochmals für Deine freundliche und sehr hilfreiche Unterstützung und Gruß.

[matty67]

Hallo Carolus,
mit dem MAX485 am ESP8266 ist es so, dass ich vor dem versenden den Kommunikationspin auf HIGH setzen muss und danach wieder auf LOW.
Hier ein Beispiel für Antworten von einigen Requests der ABL Software.

Code: Alles auswählen

#include "Arduino.h"
 
#include <SoftwareSerial.h>
#define RXPin        D1  // Serial Receive pin
#define TXPin        D3  // Serial Transmit pin
 
//RS485 control
#define SERIAL_COMMUNICATION_CONTROL_PIN D2 // Transmission set pin
#define RS485_TX_PIN_VALUE HIGH
#define RS485_RX_PIN_VALUE LOW
 
SoftwareSerial RS485Serial(RXPin, TXPin); // RX, TX
 
int byteSend;
 
void setup()  {
  Serial.begin(115200);
  pinMode(SERIAL_COMMUNICATION_CONTROL_PIN, OUTPUT);
  digitalWrite(SERIAL_COMMUNICATION_CONTROL_PIN, RS485_RX_PIN_VALUE);
  RS485Serial.begin(38400, SWSERIAL_8E1);   // set the data rate
}


String dataReceived;
void loop() {
    String answer="";
    if (RS485Serial.available()){
        Serial.print("Data svail ");
        dataReceived = RS485Serial.readStringUntil('\n');
        Serial.print("Data received ");
        Serial.println(dataReceived);
        if (dataReceived.startsWith(":010300010002F9")) {
            answer = ">010304014150BEA8";
        }
        if (dataReceived.startsWith(":01100005000102E2E223")) {
            answer = ">011000050001E9";
        }
        if (dataReceived.startsWith(":010300040001F7")) {
            answer = ">01030204E214";
        }
    }
 
    if (answer.length()>0){
        digitalWrite(SERIAL_COMMUNICATION_CONTROL_PIN, RS485_TX_PIN_VALUE); // Init transmit
        Serial.printf("Send response: %s\n", answer.c_str());
        RS485Serial.println(answer.c_str());
        digitalWrite(SERIAL_COMMUNICATION_CONTROL_PIN, RS485_RX_PIN_VALUE);// Init receive
    }
    delay(10);
}

Hier wird die Antwort gesendet.
digitalWrite(SERIAL_COMMUNICATION_CONTROL_PIN, RS485_TX_PIN_VALUE); // Init transmit
Serial.printf("Send response: %s\n", answer.c_str());
RS485Serial.println(answer.c_str());
digitalWrite(SERIAL_COMMUNICATION_CONTROL_PIN, RS485_RX_PIN_VALUE);// Init receive

Das macht, wie du schon richtig erkannt hast, der USB RS485 eigentlich automatisch.
Vielleicht fehlt dir nach dem Schreiben noch ein flush des Streams.
Das musste ich bei einer anderen Anwendung auch nach dem write bzw. print ausführen.

Ich hatte auch einen Mischbetrieb (USB RS485 an PC und MAX485 an ESP8266) ausprobiert.
Das hat auch funktioniert. Vielleicht versuchst du es mal mit zwei eigenen Programmteilen. Also ein Programm sendet eine Nachricht und das andere Programm sendet die empfangene Nachricht zurück.
Wichtig ist auch, die Kommunikationsparameter richtig zu setzen.
Also 38400, 8E1.
So wie hier z.B. RS485Serial.begin(38400, SWSERIAL_8E1);
Hat dein USB RS485 LED´s für RX und TX? Das wäre auch schon hilfreich.

Viele Grüße

Matty67

[Carolus]

Hallo Matty76,

vielen Dank für die super gute Beschreibung, die hilfreichen Tipps und das vollständige Arduino.Programm, welches ich ganz bestimmt auch verwenden werde.

Ich wage es fast nicht mehr, von meinem seltsamen "Problem" etwas zu schreiben, weil es doch sehr speziell ist und in der Community vermutlich niemanden besonders interessiert.
Wie ich schon mal früher erwähnt habe, besitze ich noch keine eMH1-WB sondern mache im Moment noch Trockenübungen mit dem ABL-Konfigurationsprogramm, zwei USB-RS485-Adaptern und einem eigenen PC-Programm, welches die Nachrichten vom ABL-Konfigurationsprogramm empfängt (funktioniert korrekt und gut) und die Modbus-Antworten (die ich von Dir gelernt habe) wieder an das ABL-Konfig-Programm zurückschickt.

Leider kommen diese Antworten dort nicht an (obwohl sie auf dem RS485-Bus übertragen werden, Nachweis durch autonomen externen Logger) oder werden einfach nicht akzeptiert, warum auch immer. Am Ende gibt es vom ABL-Konfig-Programm nach dem Bus-Scan eben die Meldung, dass keine Geräte gefunden wurden,

Die Modbus-Kommunikation funktioniert bei mir eigentlich ganz gut und mit zwei Terminal-Programmen auf beiden Seiten des RS485-Busses kann ich senden und empfangen nach Herzenslust.
Eines der USB-RS485-Adapter verwendet einen FTDI-Chip, so wie das ABL-Original-Kabel. Das scheint für das ABL-Konfig-Programm wichtig zu sein, weil es zwingend vorgeschrieben ist, die FTDI-Treiber D2XX zu installieren und ich gesehen habe, dass das ABL-Konfig-Programm,wenn es läuft, die DLL
" C:\Users\Carolus\AppData\Local\Temp\FTD2XX.dll" verwendet.
Es sieht also so aus, dass das ABL beim Konfig-Programm die Adapter-Hardware nicht per VCP-Treiber .(virtual com port) anspricht sondern über Funktionsaufrufe der genannten DLL, was FTDI ganz offiziell beschreibt und erlaubt.

Ich habe auch noch ein Testprogramm gefunden für diesen FTDI-Chip, welches auch die erwähnte DLL verwendet und auch hier funktioniert der bidirektionale Datenverkehr ohne Problem.

Besten Dank nochmals für deinen wirklich hilfreichen Support und Grüße von
Carolus

[matty67]

Hallo Carolus,
zeig doch mal bitte einen Quellcodeauszug für die Initialisierung der seriellen Schnittstelle und einen Auszug des Sendevorgangs.

[Skodi]

Hi
Vielen Dank erstmal an alle die hier ihre Erkenntnisse teilen
Ich verfolge diesen Thread schon eine ganze weile.
Ich besitze eine PV Anlage von Senec mit Home V3 hybrid duo Speicher und der Senec Wallbox pro (Baugleich mit der ABL eMh1).
Die Reglung die Senec bei der Einstellung „PV optimiert“ für die Wallbox fährt genügt mir leider nicht.
Die Wallbox hängt direkt über den RS485 am Wechselrichter und Senec steuert diese im 5 bis 10 min Takt aus Ihrem Server backend. Dem entsprechend kommt es oft zu unerwünschtem Netzbezug oder Einspeisung die völlig unnötig wären. Zudem lädt die Wallbox immer mit der PV gesammtleistung statt noch Luft für den Hausverbrauch zu lassen. Dieser wird dann während des Ladens aus dem Speicher geholt.
Um eine direktere Reglung zu ermöglichen war mein Gedanke einen Raspberry als
„Man-in-the-middle“ einzusetzen.
Der Wechselrichter fragt regelmäßigen Zustand, Strom und Spannung der Wallbox ab. Dies möchte ich durchschleifen, damit die Statistik über die Senec app bezüglich Einspeisung/Netzbezug noch stimmt
Steuerungsbefehle sollen dann nur vom Raspberry quittiert werden aber nicht zu Wallbox durchgeleitet werden.
Stattdessen soll die Wallbox dann über mqtt ansteuerbar sein, um sie zb über eine OpenWB instanz steuern zu können.

Das Ganze habe ich nun soweit auf einem Raspberry Pi 2 mit Node-Red am Laufen.
Die Verbindung zur Wallbox läuft über ein RS485 zu TCP Umsetzer von USR und die Verbindung zum Wechselrichter über einen RS485 USB stick.
Das durchleiten und rausfiltern von unerwünschten befehlen funktioniert schon mal.
Das setzen der Ladeleistung über mqtt funktioniert auch.
Was mir jetzt noch fehlt ist, dass, wenn die Wallbox mir auf die Anfrage nach Spannung (:010300150005E2) und nach Strom (:0103000F0005E8) antwortet, ich mir aus dieser Antwort die werte in Volt und Amper errechne.
TKI hat ja bereits geschrieben das die Antwort beim z.B Strom folgend aufgebaut ist:
0x33 <Byte X> <Byte Status> 3 mal <Byte Strom Phasen L3, L2, L1>
Aber wie rechne ich das jetzt um damit ich den Amperwert als dezimal zahl habe?
Meine Wallbox meldet mit bei nicht angeschlossendem Fahrzeug folgendes:
>0103 0A 0F94 0215 010B 010B 010B 14
010B müste ja demnach 0 Amper sein oder? Wenn ich das aber von Hex zu dezimal umrechne komme ich auf 267. Gibt es da noch einen Faktor, mit dem man das umrechnen muss oder ähnliches?

Viele Grüße
Skodi

[matty67]

Hallo Skodi,
die Umrechnung erfolgt nach irgendeinem Standard. Ich nehm´ die Formel val / (26.7 / 16.0) / 10
In deinem Fall mit val = 267 folgt: 267 / (26.7 / 16.0) / 10 = 16A. Du müsstest noch den Status abfragen, um zu erkennen, ob ein Kfz angeschlossen ist.
Ich lese immer den Status (0x2E). Da sind alle Angaben drin.

Viele Grüße
Matty67

[Carolus]

Hallo Matty67,

ich bin nach vielen Versuchen und mit Hilfe von genialen Tools (MS-SysInternals + SerialPortMonitor/Fa. Eltima) glücklicherweise endlich weiter gekommen.

Dadurch habe ich gesehen, dass es ein ABL-Logfile gibt (bei mir unter: "C:\Users\Carolus\AppData\Local\VirtualStore\Program Files (x86)\ABL Configuration Software\app\evcc-config-log.log"), in dem mein Problem beschrieben war: "Timeout".

Der Grund dafür war aber nicht, dass meine Antworten nicht oder zu spät ankamen, sondern die gesendeten Zeichen waren einfach verfälscht.
Mit Hilfe des zweiten Tools konnte ich dann sehen, dass ABL im Gegensatz zum EVCC1 beim EVCC2 offensichtlich bei der Schnittstellen-Einstellung Parity.Even verwendet.
Mit dieser Anpassung bei meinem Programm kamen die Zeichen meiner Antwort-Telegramme dann endlich richtig beim ABL-Konfig-Programm an.

Ich habe dann auch noch gesehen, dass ABL die Antwortstrings nur bis CR (0x0D) scannt, ein nachfolgendes LF (0x0A) erscheint dann schon am Anfang der nächsten Antwort-Message. Somit reicht ein CR am Ende der Antworten.

Also, wie gesagt, ich bin richtig happy und besonders Dir auch wirklich dankbar für Deine Geduld und die hilfreichen Tipps, die ich bekommen habe.

Ich kann mich der Meinung von Skodi wirklich nur anschließen, es ist großartig, dass so viele ihre Erkenntnisse in diesem Forum so freigiebig an die Allgemeinheit und an Gleichgesinnte weitergeben.

Gruß, Carolus


(p.s.: bitte entschuldige meinen Zahlendreher beim letzten Mal)

[matty67]

Hallo Carolus.
Na endlich. Das war ja eine schwere Geburt.
Das mit den Parametern hatte ich dir doch schon am 21.04. geschrieben. (Haha) Wahrscheinlich hast du es überlesen.

Wichtig ist auch, die Kommunikationsparameter richtig zu setzen.
Also 38400, 8E1.

Bin gespannt, wie es jetzt bei dir weiter geht.
Viel Erfolg und viele Grüße.

Matty67

P.S. Den Zahlendreher hatte ich gar nicht gesehen. Baujahr 76 wär natürlich schöner.

[Carolus]

Hallo matty67,

Du hast recht, mit Brille wäre das nicht passiert. Es ist mir schon etwas peinlich, dass ich nicht genau hingeschaut habe. Danke für Deine Geduld !

Inzwischen kann ich in mehreren Schritten mit dem ABL-Konfig-Programm kommunizieren und komme tatsächlich bis zum Ende durch, bei dem dann das Konfig-Programm aufhört zu fragen und zufrieden ist (so wie ich auch).
Eine große Hilfe war dabei Deine Beschreibung (und die von TKI) und das ABL-Log-File, welches ich vor kurzem erwähnt habe. Hier steht einiges im Klartext drin und hat mir sehr geholfen, die Hürden Schritt für Schritt zu nehmen bis alles am Ende zufriedenstellend durchgelaufen ist.

Kennst Du (oder vielleicht auch jemand anderes) evtl. noch die Bedeutung der Register (Bit-Codierung ?), die bei der Status-Abfrage (0x002E) zurückkommen ?
(z.B. >0103 0A 2EB2 D064 03E8 03E8 03E8 1D (B2 connected = true; chargerelease = true; charging = false;) nicht laden)

2EB2 ist offensichtlich die Registernummer 0x2E + die Status-Info "B2", aber was steckt hinter D064 und 3x 03E8 ?
Sind letztere evtl. die drei Strom- oder Leistungswerte der drei Phasen ?

Vielen Dank für Deine Hilfe und Gruß
Carolus_52

[matty67]

Hallo Carolus,
der erste Wert ist der maximale Strom. Die Bedeutung des D von D064 kenne ich nicht. Also wird nur mit 064 gerechnet.
064 in hexadezimal -> 100 in dezimal

Also mit der Formel ergibt das dann 100 / (26,7 / 16) / 10 = 6A

Die anderen 3 Werte sind die Ströme der 3 Außenleiter.
Die ändern sich von 3E8 bei angeschlossenem Fahrzeug auf den aktuellen Ladestrom.


Die anderen Werte kannst du der Auflistung entnehmen.

Code: Alles auswählen

(6A) 064
(7A) 075
(8A) 086
(9A) 096
(10A) 0A7
(11A) 0B8
(12A) 0C8
(13A) 0D9
(14A) 0EA
(15A) 0FA
(16A) 10B

Der Wert 3E8 (also 1000 dezimal) gibt an, dass nicht geladen werden soll. Also so eine Art Ladesperre.


Viele Grüße
Matty67