Diverting Solar to Charge an Electric Car

Hi BR and Glyn; Many thanks for your assistance - I guess I have now settled on a solution. Both of you have recommended a hardware solution to obtain the serial input, which I will now attempt. The issue regarding the need to input a feed into Node RED is so I can use the actual amps from the CTs. I did not want to use a constant to convert the kW as the voltage is too variable. Using the input vrms with the appropriate energy feed could not be better. I intend to keep all the charging algorithms as already developed in the Smart EVSE as they are excellent, they work exceptionally well to dynamically maximise the charging rate. I only need a very simple manipulation of the grid connection current prior to passing to the Smart EVSE for dynamic solar only charging. If the connection to the Smart EVSE works it will be a simple 4 or 5 step Node RED program, switchable between max possible charge for a last minute range charge and normal daily solar charging cycling around 50% battery capacity. At least thats what I hopeā€¦
Now the work begins.
K

Cool, just two notes:

My name is not BR. I used it at the end of the text as BR = Best Regards. Not anymore! :slight_smile:

Actually you only need Amperes to make this work. Canā€™t you just avoid Power? Or the smartevse needs to receive power figures in the communication?

Good luck!

Hi. Please forgive my misunderstanding of how forums operate and are signed; I have never used a forum (or any social media) prior to my purchase of emonPi; I asked for help from the emonPi team and they advised I should use these forums. I am out of my depth and extremely uncomfortable; I just wish I could have talked to someone regarding my issues for 10 minutes. I persevere because I want to do this work.
I am intrigued by your reply; it is Amps I am after. The standard (normal?) inputs are power so I need to divide this input by vrms for amps. I tried to create a new ā€œinputā€ which was easily accessible by Node RED, but I could not make both power and arms dynamic to provide the resultant dynamic Amps. I have only been able to do this creating a virtual feed - hence my problem in trying to pick up this virtual feed value in Node RED. I am obviously missing something?
Again, apologies.
K

Hey no worries.

Since the elementary measurements are volts and amperes, the power feeds you see are a result of a calculation that you want to revert back to amperes. Maybe there is a way to use the amperes directly from the original measurements. On the emonpi i donā€™t know, but on the emontx it is as simple as exposing these variables in the arduino sketch and send them along the other values. And on the emonhub i just report them to emoncms and MQTT simultaneously and iā€™m done.

Iā€™m sure someone experienced with emonpi will help you use amperes and route them to node-red for processing.

On the smartevse side, how will it work? What will you feed to the EVSE?

The Atmel processor inside the emonPi runs a sketch that does essentially the same as the emonTx (itā€™s available on GitHub via Resources), but to make the current available, youā€™d have to modify and reload the sketch, which is a bit cumbersome. The process is documented, again via Resources.

Hi again;
To feed the EVSE for max charge rate I will supply the EVSE input with the actual amps measured on the supply. This is as the EVSE software is designed; it does a really good job of charging at the rate that is the difference between the set Maximum Current possible and the actual use. When Solar Only charging is required I intend to switch this input to a calculated value of Maximum Current + actual excess solar (which is -ve when solar power is available). This will feed the EVSE with a value that will enable the charging algorithms to utilise the excess solar; as the solar varies so will the input and hence so will the charge rate. This is a very simple Node RED proposition; it works easily with Power1 divided by a fixed value for voltage, but I would like to be more accurate if possible as I do get a voltage variation. I also have to get the Node RED output to a serial connection, so following the advice above I have ordered a few different USB to Serial devices to see if any will work. I still spend hours trying to get Node RED to operate on the Power1 and VRMS inputs but I am only be able to do this successfully as a Virtual Feed, and try as I might I cannot get this into Node RED. I have seen in the Forums that this has proven difficult to others in the past. Roberts advice above is probably beyond my current skills, but hey - gotta try!
Thanks for the support, it is appreciated.

How will the smartevse behave when the value you feed him is above the max and the charging amps are set at 6A? The charging stops? What happens next?

I have some flexibility and will need to decide. There is a MaxCurrent setting which is the maximum house supply size; the combined house load and charging load cannot exceed this; SmartEVSE will stop charging if it runs out of available current, with 6A as its minimum. The Tesla does not have any issue with a charge being interrupted; it will resume charging when the pilot is re-instated. I have been running with a simple timer turning the charger on/off during the expected sunshine productive hours without issue; it will restart immediately if I cancel the timer straight after the off. In my case, using a Tesla single phase 63A charger, the Maximum Charging possible is the same as my MaxCurrent (63A). I could set these figures to either turn off the charger when the solar power available is less than 6A; or allow the SmartEVSE to keep charging at a minimum of 6A from the grid when the solar disappears. I will probably do the latter to stop any instability; at my location here in Australia when the sun shines and the solar is producing, it becomes a very stable charging environment which just requires the EVSE adjustment to follow the morning generation rising, and the afternoon fall off in power reduction. The timer will stay in the circuit.

Thanks for the explanation, i agree with you that the car should keep charging at a minimum instead of constantly restarting the charge process.

As a offtopic, do you know what is the efficiency of the tesla charge at 6A? I am trying to build some datapoints from several cars to calculate a rough approximation of ā€œliquidā€ kWh that enter the battery on my EVSE. I figured the Leaf/Fluence and Zoe, but for the Tesla i only found tests that start at 20A.

I now have received several different USB to Serial devices and I am attempting to output a serial connection from Node RED. When I use the serial output node as advised to /dev/ttyUSB1 I get Error: Cannot open /dev/ttyusb1. How do I open /dev/ttyusb1? And does it matter which of the 4 USB ports I am using (they are not numbered)?

Regarding the charging efficiency of the Tesla I am happy to help - what measurements / increments would you like? I can charge the Tesla selecting 1A increments on the charge screen.

Hi again. I have now received and connected the emonPi USB2UART to one of the USB ports, and still the Node RED serial output node (set to /dev/ttyusb1 as suggested) gives the result in the debug ā€œError: Serialport /dev/ttyusb1 not openā€. Searching the forums does not provide an answer to ā€œhow do I open the serial portā€, and Raspberry Pi forums do not assume the serial port is taken by connection to the emonPi. I am still searching; does anyone know how this is done?
Also still happy to make measurement around the Tesla charging at lower currents; what is required?

Hi Keith, you should go to a command line on the RPi and write ā€œdmesgā€ after you plug your USB device. If the device is recognized and the drivers are loaded you will get the correct path.

Regarding the Tesla, from some snapshots found on a Tesla forum, it seems that at 120V 12A the Tesla can be as inefficient as 53%, which is pretty terrible. are you able to find the efficiency at 6A, 230V? That is the bare minimum in Portugal. I suppose it will be very inefficient. From what I found, I believe that from 20A up the efficiency of the charger will be at its best.

The source for the 53% is here: Charging | Tesla

regards.

1 Like

Thank you - your ā€œdmesgā€ worked wonders. Relief. Now I understand that the USB numbers start at 0 and are specific to a particular outlet and I am able to connect. The next issue is how I construct the required string in the function node to pass to the serial output. Providing 0x5001 in a string for serial output and calculating a crc16 checksum requires a very steep learning curve.
Regarding the Tesla, I will attach the solar CT to the charger input and charge for 1 hour at various low current settings, noting the input energy and the kms gained. I think this will match the data from the Tesla calculator. Will 6, 10 and 14A be sufficient? Bear in mind that I have a P90D with the optional twin onboard chargers; I do not know if the battery capacity and the twin chargers affect the efficiency compared to your existing figures. I think that the twin chargers are staged so that on smaller currents the overhead is minimised, but I may be wrong.

Good to know you are overcoming the challenges. for the CRC16 csum i found some code, maybe it can be used for your case ā†’ node-red-beanserial/102-BeanSerial.coffee at master Ā· doraess/node-red-beanserial Ā· GitHub

there is also a npm package somewhere with crc16, but i am not very good at this NodeJS stuff.

for the charger test, it would be great if you could perform them. are the Km gained a good stable reference? Because the Nissan Leafā€™s Km estimate is really no more than a guess. Thatā€™s why it is kindly called guess-O-Meter :smile:

I found an npm package at GitHub - alexgorbatchev/node-crc: Blazingly fast CRC implementations for node.js and browser, your reference appears to have a very different structure. My challenge is to write a function that outputs the following string to the serial node, being
,,,<sample 1><sample 2><sample 3>,
where protocol = 0x5001 (2 bytes), version = 1 (1 byte), nr of samples = 3 (1 byte) - samples are 4 bytes (double); #1 being a calculated value in JavaScript (already a double), #2 and #3 being zero
crc16 is 2 bytes, all followed by the message crc.
This is looking to be beyond what I can do so I am going to talk to a professional programmer next week.

In the meanwhile:
Charging test using emonPi at Tesla selected charge rate of 6A on Tesla P90D (90kWh battery pack).
Note: Tesla battery management system heats / cools the battery pack as required; this energy forms part of the charging cycle. Temperature may therefore be important.
Charging power measurement: CT/emonpi on wall mounted Smart EVSE live feed.
(CT was calibrated to match ABB PowerOne inverter output).
Start: Battery at 51% (Tesla display) at 9:32am
Tesla interior temperature 13.9 deg (Winter morning, car garaged)
Charge for 8 hrs
Sunny day, (good Solar PV output!), outside temp peaked at 13.5 deg 2pm
Finish: Battery at 62% (Tesla display) at 5:32pm
Tesla interior temperature 18.4 deg
Results
Input power from emoncms 11.7 kWh at 5:31pm
Charge session power to battery (according to Tesla display) 9kWh at 5:32pm. This increased to 10kWh during charging shutdown at 5:36pm; Input energy at this time 11.8kWh.

Problem: Inaccuracies due to Tesla power display and battery state of charge showing only whole numbers.
Estimated efficiency: Between 9/11.7 and 10/11.8, or 77% to 85% at 6A

10A tomorrow.

Hi Keith, thanks a lot for this, if you donā€™t mind can you do the next test at maximum charge rate, instead of 10A? This way i get a rough estimate of the limits.

regarding the PPP protocol, have you tried reaching the SmartEVSE author? Maybe heā€™s also interested in having this kind of integration, thereā€™s no doubt that what you are doing increases the value of that EVSE considerably :wink:

I have been in contact with the Smart EVSE author who has offered both detailed information and encouragement, but who has not used Node RED. A very experienced NodeJS programmer here in Melbourne has expressed interest in assisting, meeting today.

Second Tesla test with 40A selected. Max with the twin chargers is 3ph 32A, or 96A/23kW, but I do not have 3 ph at home, and my 63A EVSE is being rebuilt with the Smart EVSE controller.
Start: Battery at 47% (Tesla display) at 4:56am
Tesla interior temperature 14.0 deg
Early morning outside temp 10 deg
Charge for 2 hrs
Finish: Battery at 68% at 6:58am
Tesla interior temperature 14.0deg
Results
Input power from emoncms 18.0kWh
Charge session power to battery (according to Tesla display) 17kWh

Inaccuracies due to Tesla power display being whole numbers only, as before.
Estimated efficiency 17/18, or 94%
A definite improvement over 6A

Just for closure - the emonPi is now connected to the Smart EVSE, and is providing the necessary current feedback to the controller to effect both smart maximum current charging and solar charging. Node RED flows provide the required input for these two different operational cases.
Two remaining issues are the approximation of the current (power/235) as I was unable to use the actual emonPi amps, and the sampling rate (5 seconds) of the emonPi which allows for the growth of spikes that trip the EVSE during some edge conditions only. Under ā€œnormalā€ conditions the system tests out well (and has successfully charged the car!).
I would like to thank those who answered my very basic and probably misconstrued questions; as I am an absolute beginner in these matters I have welcomed the support given.

1 Like

Hi keith, thanks for the charging tests, Iā€™ve included them in my ā€œliquidā€ kWh calculations.

Regarding your communication challenge congratulations for making it work.

In my system i have a 10s sample rate and havenā€™t got yet any issue. The circuit breakers are thermal so they can handle spikes well above contracted power. But I had to tweak the maximum allowable EVSE charge power down from 30A to 25A. Having 5A headroom appears to be enough in my case.

Nice work! Would be great if you could write up your setup with some photos. I would love to publish a blog post on this application using emonPi in the OpenEnergyMonitor blog. Iā€™m thinking about getting an EV myself and @TrystanLea already has a Nissan Leaf :slight_smile: