Smart EVSE

Moin, moin,
ich versuche jetzt mit M. Stegen, neben dem NORMAL- u. SMART-mode einen neuen RC-mode zu schaffen, der eine simple Stromvorgabe aus externer Quelle ermöglicht. Das CLI bietet sich wegen der permanent wechselnden Vorgabewerte eher nicht dazu an, da dort m.E. alle values im EEPROM gespeichert werden.

Es muss doch neben dem anspruchsvollen SMART-mode möglich sein, nicht nur mit fix eingestelltem Max-Wert zu laden (NORMAL-mode). Ich denke, dass dafür ev. der UART2, der für's Flashen und für's CLI verwendet wird, geht.
UART1 wird ja für die RS485-Leitungen zur Sensorbox genutzt.

Hintergrund:
Für eine mobile WB würde ich gern per BT-UART-module oder alternativ ESP8266/ESP32 die config remote vom phone per APP vornehmen.
Bei einer Festinstallation kann damit auch der variable Vorgabe-Ladestromwert von einem externen EMS per WLAN zugeführt werden.

Mal sehen, was er von meinen Vorschlägen hält.
VG U x I

[Tho]

Oder ein weiteres CLI Command, was nicht in den Flash schreibt und nur zur Laufzeit aktiv ist?

[umali]

Ja Tho,
das ist wahrscheinlich noch einfacher, weil man den RS485 an UART1 so lassen kann, wie er ist (Erhaltung der SMART-Funktion).
Statt USB/UART ((FTDI) für's Flashen bw. das CLI wird einfach einer der o.g. wireless Adapter verwendet. Lt. source code müsste das UART2 sein.

Auszug von hier:
https://github.com/SmartEVSE/smartevse/ ... 2.X/EVSE.c

Code: Alles auswählen

// Global data
char	U1buffer[50];               // Uart1 Receive buffer /RS485
char	U1TXbuffer[50];             // Uart1 Transmit buffer /RS485
char	U2buffer[50];              	// Uart2 buffer /Serial CLI
char	Tbuffer[50];                // temp buffer
char GLCDbuf[256]; // GLCD buffer (one row double height text only)

Etwas SW-Anpassung müsste aber noch vorgenommen werden. Am besten ganz simple den zusätzlichen "RC"-mode als Alternative zu SMART und NORMAL einführen. Damit ist dann klar, dass bei der vorher durchgeführten EEPROM-Einstellung RC (über CLI) nur die Laufzeitvariable für die externe Stromvorgabe genutzt wird. Damit bliebe der bisherige code erhalten.
Was meint Ihr?

Im übrigen dürfte der neue 5W ACDC in der smart EVSE v2 vermutlich ausreichen, um auch einen ESP32 mit zu versorgen. Der zieht wohl unter 1W. Damit könnte man dann mit smartphone/APP auch timer-Funktionalität in den ESP32 auslagern. Der timer schaltet dann nach einmaliger Einstellung an der APP unabhängig ab, wenn z.B. die gewünschte Lademenge erreicht wurde.
Das würde ich zunächst nur als ca.-Wert über die APP-Stromvorgabe + timer, also nicht über echt gemessene Werte, realisieren wollen. Wer's genau braucht, kann ja einen extra Zähler einbinden. Dieser kann z.B. auch vom ESP32 ausgelesen werden (z.B. echter WLAN-Zähler oder SDM630 Modbus RTU mit RTU/WLAN-Umsetzer).
VG U x I

[Tho]

Etwas SW-Anpassung müsste aber noch vorgenommen werden. Am besten ganz simple den zusätzlichen "RC"-mode als Alternative zu SMART und NORMAL einführen. Damit ist dann klar, dass bei der vorher durchgeführten EEPROM-Einstellung RC (über CLI) nur die Laufzeitvariable für die externe Stromvorgabe genutzt wird. Damit bliebe der bisherige code erhalten.
Was meint Ihr?

Das wäre meines Erachten nach der beste Weg.
Die Idee hatte ich auch schon mal, um die SmartEVSE mit SEMP (SMA Sunny Home Manager) steuerbar zu machen.
Der Change im Code ist ja relativ überschaubar für Stegen.

Na schaun' mer mal. Meist dauert es etwas, bis er reagiert. Ich halte Dich auf dem Laufenden.
VG U x I

Hey,
der Michael Stegen ist echt schnell. 1a support!

Die Idee mit zusätzlichem command in der CLI und Laufzeitvariable im RAM hat er als machbar bestätigt. Zusätzlich neuer mode.
Ich habe ihn gebeten, das umzusetzen und mir das Datenformat des Vorgabestromwertes vorzugeben (am UART2). Ich würde dann auch gern den Donate-button drücken - ev. andere hier auch.

Zunächst versuche ich dafür eine APP zu bauen, die aus diversen Vorgaben des users (Ladekennwerte des EV, Kennwerte des Ladepunktes) den gewünschten Stromvorgabewert erzeugt und per BT an die smart EVSE sendet. Ein timer muss dann erstmal auf dem phone laufen. Später kann das BT-modul durch einen ESP32 ersetzt werden.
Ich probiere es als newbie mit "App inventor2". Das klappt ganz gut.
Gibt's hier ev. freaks mit mehr knowledge, um mitzuhelfen? Ich würde es auf github einstellen.

Dann kann natürlich auch die remote controlled version mit variablem Stromvorgabewert umgesetzt werden. Das würde sicher einigen PV-lern viel helfen. Z.B. könnte versucht werden, mit eigenem EMS auf null zu regeln.

Michael möchte den neuen mode EXTERNAL nennen, was ich eine sehr gute Idee finde. Hab's bestätigt.

VG U x I

[leonidos]

Würde mich auch interessieren.
Danke für die Initiative und die Infos

[anko]

Hi all,

I do apologise for addressing you in English, but I am afraid my German is not good enough to properly convey my query. I will be able to read and understand answers in German, though

I have a 3 x 25 amps grid hookup.

I have two SmartEVSE modules, one uses L1 + L2 (for a Tesla), the other uses L3 (for an Ampera E).
I have a sensor box so I can use the modules in smart mode.

See my problem? When L3 is heavily loaded, it will impact both modules, not just the one that uses L3.
Rather than going for two sensor boxes, I have put my modules in Slave mode and I use a RPI Zero W as Master.

The PI receives current info from the sensor box for all three phases and controls the slaves. The PI responds to requests from the Slaves and it sends regular current broadcast messages.

So far so good. Except that every now and then (this can be after 5 minutes or several hours) both Slaves switch from Charging mode to Ready Mode for no apparent reason. As if the have not received the broadcast messages for too long.

I have already noticed that the slaves have issues with the broadcast message if the broadcasted current is 7 (0x07) or 11 (0x0B). I have escaped these bytes (the same way other special bytes are escaped) but that has not helped.

So now, whenever the calculated current for a slave is 7 or 11, I change it to 6 or 10 before sending the broadcast message. Now the problem occurs far less frequent. But it still does. and I don't know why.

Anybody here recognises any of this?

BTW: Going for a second sensor box would probably be much easier, but ultimately I want to be able to 'disconnect' L3 from the second module and 'connect' it to the first module when the second module is not in use: When the Ampera E is charging the Tesla will charge on 2 phases. When the Ampera E is not charging, the Tesla can charge on three phases. That line of thinking.

Vielen dank im voraus,

Anko

[leonidos]

Try to open an issue here:
https://github.com/SmartEVSE/smartevse/issues

[anko]

Try to open an issue here:
https://github.com/SmartEVSE/smartevse/issues

Thanks, that is of course an option. But before I do that, I would prefer to know whether others have experienced similar behaviour.