Any Downside To (Relatively) Frequent Amperage Changes During Charging?

[Haselsmasher]

I've written a small python program that periodically 1/ looks at our electric meter to see if we're sending power (from our solar panels) to the grid or pulling from the grid and then 2/ adjusting Tesla charging (either starting charging, stopping charging, or changing amperage) so we minimize what we pull from the grid just to charge the car.

Today in CO it was partly cloudy so solar panel output was pretty variable through the day. Add to that consumption in the house changes through the day. The result is what is "leftover" at any given moment that can be applied to the car can change pretty frequently.

I'm wanting to poll the status of the meter and potentially change the charge settings every 2-3 minutes.

Does anyone have any opinion if that could hurt the car in any way?

I can do what I describe above manually in the app. (It's just a PITA.) I'm kind of figuring if there was an issue with changing the amperage setting too frequently the app would prevent us from doing so.

Thanks.

Jim

 

[power.saver]

Should be okay. Tesla's Powerwall does something similar during a grid outage.

Vehicle Charging During Power Outage | Tesla Support

Powerwall now coordinates with Tesla vehicles during a power outage to charge your car without exceeding the energy and power capabilities of your Powerwall.

www.tesla.com

 

[Haselsmasher]

Should be okay. Tesla's Powerwall does something similar during a grid outage.

Vehicle Charging During Power Outage | Tesla Support

Powerwall now coordinates with Tesla vehicles during a power outage to charge your car without exceeding the energy and power capabilities of your Powerwall.

www.tesla.com

Thanks!

 

[KaJeh]

I've written a small python program that periodically 1/ looks at our electric meter to see if we're sending power (from our solar panels) to the grid or pulling from the grid and then 2/ adjusting Tesla charging (either starting charging, stopping charging, or changing amperage) so we minimize what we pull from the grid just to charge the car.

Today in CO it was partly cloudy so solar panel output was pretty variable through the day. Add to that consumption in the house changes through the day. The result is what is "leftover" at any given moment that can be applied to the car can change pretty frequently.

I'm wanting to poll the status of the meter and potentially change the charge settings every 2-3 minutes.

Does anyone have any opinion if that could hurt the car in any way?

I can do what I describe above manually in the app. (It's just a PITA.) I'm kind of figuring if there was an issue with changing the amperage setting too frequently the app would prevent us from doing so.

Thanks.

Jim

Very interresting question: i struggle with the same issue when i try to charge solar only. I set the charging current in the app to the mimimum (5A; three phase) during sun hours manualy. This works in summer and cloudless sky. But not in the other time of the year. A program would be of great help. I do not have a tesla home battery. Do you find a solution allready?

 

[Big Earl]

The only thing I would recommend avoiding is stopping/starting charging frequently, as that adds cycles/wear to the contactors. Frequent amp changes won't hurt anything.

 

[Haselsmasher]

Very interresting question: i struggle with the same issue when i try to charge solar only. I set the charging current in the app to the mimimum (5A; three phase) during sun hours manualy. This works in summer and cloudless sky. But not in the other time of the year. A program would be of great help. I do not have a tesla home battery. Do you find a solution allready?

I did. I've gotten a program I've written to work quite well IMHO. As the sun comes up in the morning and solar is produced it starts the car charging - and charging amps increase as solar production through the day increases. As consumption in the house changes (cooking, laundry, etc.) and solar production changes car charging is changed accordingly.

The "weakest link" is having a method to read the electric meter - to get the net-meter for whether energy is being pulled from the grid or being sold back to the grid. I'm using an Eagle-200 (by Rainforest Automation) which connects to the meter - but it is a finicky device and getting it going can sometimes be a challenge.

The code is on GitHub. But... the most recent version there (v1.2) has some issues. I've re-architected the solution. I'm currently working out some bugs but it should be up there in the next week or two I'd guess.

GitHub - Haselmaier/Suncatcher

Contribute to Haselmaier/Suncatcher development by creating an account on GitHub.

github.com

 

[power.saver]

I did. I've gotten a program I've written to work quite well IMHO. As the sun comes up in the morning and solar is produced it starts the car charging - and charging amps increase as solar production through the day increases. As consumption in the house changes (cooking, laundry, etc.) and solar production changes car charging is changed accordingly.

The "weakest link" is having a method to read the electric meter - to get the net-meter for whether energy is being pulled from the grid or being sold back to the grid. I'm using an Eagle-200 (by Rainforest Automation) which connects to the meter - but it is a finicky device and getting it going can sometimes be a challenge.

The code is on GitHub. But... the most recent version there (v1.2) has some issues. I've re-architected the solution. I'm currently working out some bugs but it should be up there in the next week or two I'd guess.

GitHub - Haselmaier/Suncatcher

Contribute to Haselmaier/Suncatcher development by creating an account on GitHub.

github.com

I like what you're doing and looked over the code on github. Thanks for posting that.

I have Rainforest Eagle devices connected to my meters (two of them) and they have worked reliably since 2010.

I notice you use a completely different set of XML commands to request the meter data. Maybe this is specific to the Eagle-200, but you might want to try what I'm using:

<LocalCommand>
  <Name>get_instantaneous_demand</Name>
  <MacId>0x0000000000000000</MacId>
</LocalCommand>

Here's another one that returns the summation data from the meter, useful if you want to track usage over time:

<LocalCommand>
  <Name>get_device_data</Name>
  <MacId>0x0000000000000000</MacId>
</LocalCommand>

I poll for the instantaneous demand once a minute and the device data (summation) every 5 minutes. Replace the all-zero MacID with your device's info. These commands are directed to port 5002 on the Rainforest Eagle device.

Although I don't use JSON for the response, the documentation I have says it supports the <Format>JSON</Format> tag.

 

[Haselsmasher]

I think, but not totally sure, the API commands were changed when Rainforest went from the Eagle to the Eagle-200.

I like your idea of polling for summation data. I've wondered if it would be more effective/realistic to base a car charging adjustment on something broader than ID. For example, I happen to be warming a slice of pizza for lunch when the sw polls for power status - and a decision is being made based on an event that will last less than 1 minute. I'll look into that.

I wasn't very clear in my reference to the Eagle-200 being finicky: Once I got my unit provisioned with the electric utility (meaning them doing what needed to be done on their end to get the meter to connect with the Eagle-200) things have worked well. My Instantaneous Demand requests of the unit have worked quite reliably. Occasionally it generates an error...these usually get better after a little while. On one or two occasions I've cycled power on the unit and that has resolved things. But.....

I'm helping a friend get what I've put together running at his house (same utility). The Eagle-200 has paired with the meter. And I can get Instantaneous Demand data. But the Rainforest Cloud reports the data as being two hours earlier than reality. This doesn't impact the car charging solution - since ID data retrieved via the API is accurate. But it's making the overall user experience with the Eagle-200 sub-optimal.

He and I are kind of stuck in the middle between the utility and Rainforest. Rainforest is saying the meter's time is wrong. The utility is saying the meter's time is correct. IMHO the problem points more to Rainforest than the utility (the city only experiences these time-lag issues with Eagle-200 devices....every other device they connect works perfectly.....including other Rainforest devices). But Rainforest is unequivocally stating it's the meter's problem. Argh.

 

[power.saver]

I think, but not totally sure, the API commands were changed when Rainforest went from the Eagle to the Eagle-200.

I like your idea of polling for summation data. I've wondered if it would be more effective/realistic to base a car charging adjustment on something broader than ID. For example, I happen to be warming a slice of pizza for lunch when the sw polls for power status - and a decision is being made based on an event that will last less than 1 minute. I'll look into that.

I wasn't very clear in my reference to the Eagle-200 being finicky: Once I got my unit provisioned with the electric utility (meaning them doing what needed to be done on their end to get the meter to connect with the Eagle-200) things have worked well. My Instantaneous Demand requests of the unit have worked quite reliably. Occasionally it generates an error...these usually get better after a little while. On one or two occasions I've cycled power on the unit and that has resolved things. But.....

I'm helping a friend get what I've put together running at his house (same utility). The Eagle-200 has paired with the meter. And I can get Instantaneous Demand data. But the Rainforest Cloud reports the data as being two hours earlier than reality. This doesn't impact the car charging solution - since ID data retrieved via the API is accurate. But it's making the overall user experience with the Eagle-200 sub-optimal.

He and I are kind of stuck in the middle between the utility and Rainforest. Rainforest is saying the meter's time is wrong. The utility is saying the meter's time is correct. IMHO the problem points more to Rainforest than the utility (the city only experiences these time-lag issues with Eagle-200 devices....every other device they connect works perfectly.....including other Rainforest devices). But Rainforest is unequivocally stating it's the meter's problem. Argh.

Yes, Rainforest has less that impressive customer support. And I have heard that the Eagle-200 is an inferior product from the original Eagle (many features stripped out of the API). I wouldn't be surprised if the time lag was their problem.

I don't use their cloud service and just poll the local device on the API for my own needs.

Taking an ID average over a few samples (minutes) would help with those short power draws like the microwave or other appliances. Maybe keep a rolling 5-minute average of the demand, so you're ready to adjust to a big shift in load, but can ride through any short bursts.

I've got to get going on my car charging connection. You have done what I want to do.

 

[slcasner]

He and I are kind of stuck in the middle between the utility and Rainforest. Rainforest is saying the meter's time is wrong. The utility is saying the meter's time is correct. IMHO the problem points more to Rainforest than the utility (the city only experiences these time-lag issues with Eagle-200 devices....every other device they connect works perfectly.....including other Rainforest devices). But Rainforest is unequivocally stating it's the meter's problem. Argh.

I have a similar problem with a different device. I'm using the Universal Devices ISY-994i home automation controller with their SEP Zigbee radio interface added in. The InstantaneousDemand query sometimes returns a bogus value of -8388.608 which happens to be the most negative 24-bit value (0x800000). I've tried raising a case with both UD and PG&E but each just points a finger at the other. So I just ignore that bogus value. As @power.saver is suggesting, I have also decided that using deltas of the net meter reading is more reliable. But I also have Powerwalls now so I have a separate source of grid flow data.

Thanks for posting your code. I don't have PTO yet so our system is running in non-export mode. That means when the Powerwalls fill up the solar shuts down and goes to waste. I have been plugging in our various EVs and manually adjusting charge levels to capture as much as I can. Your code shows how to automate this for our Model Y.

 

[SolarPoweredY]

I have a similar problem with a different device. I'm using the Universal Devices ISY-994i home automation controller with their SEP Zigbee radio interface added in. The InstantaneousDemand query sometimes returns a bogus value of -8388.608 which happens to be the most negative 24-bit value (0x800000). I've tried raising a case with both UD and PG&E but each just points a finger at the other. So I just ignore that bogus value. As @power.saver is suggesting, I have also decided that using deltas of the net meter reading is more reliable. But I also have Powerwalls now so I have a separate source of grid flow data.

Thanks for posting your code. I don't have PTO yet so our system is running in non-export mode. That means when the Powerwalls fill up the solar shuts down and goes to waste. I have been plugging in our various EVs and manually adjusting charge levels to capture as much as I can. Your code shows how to automate this for our Model Y.

Will this run on my Synology?

 

[slcasner]

Will this run on my Synology?

I don't think your question was for me since I described a particular hardware interface. Perhaps for the OP, @Haselsmasher?

 

[holeydonut]

Cross posting what @jgleigh shared in the Energy subforum... there's an app called ChargeHQ that is in beta. I think this tool assumes your solar production and home energy consumption also tracked by the Tesla App ecosystem, and that you have a Tesla vehicle. In my case I have Tesla Powerwalls and my solar generation + home energy is in my app... and my wife has a Model 3.

Once you authorize ChargeHQ to connect to your Tesla Account, it will instruct your car each minute to charge at a rate equal to the solar array output minus the measured home loads (excluding the EV charger itself). This way your car soaks up all the solar power that would normally be pushed to the grid; and the net grid impact is effectively zero during that time.

Below is what it looks like on a slightly cloudy day in graph-form.

Up to about 11am, the solar charges the powerwalls (in green). The Tesla Powerwall setting I use sends all solar generation into the powerwalls, and the home draws from the grid during this time. Since the powerwalls refresh their charge rate constantly, the blips in the solar generation curve are soaked up.

Starting around 11am, ChargeHQ tells the car to start charging. It modulates the charge rate each minute to attempt to make the car soak as close to a net-zero grid impact as possible while charging. You can see the clouds moving in/out and fluctuations in my other home loads aren't perfectly matched to the car's charge rate. That is why the blue overlay doesn't exactly match the solar line graph.

Once the EV is charged, then the excess solar that my home didn't use is pushed to the grid. I like this since I can then say with more confidence that the car is being charged by solar; instead of from the Grid (to the extent I have enough solar).

The only drawback so far has been my solar system sometimes has odd behavior that I have never seen before. Basically my solar array gets taken offline sometimes when ChargeHQ is doing its thing. This makes no sense to me; and seems like a fluke. But I posted more about it here:

Gen3 Home Charging with powerwalls

Hi, apologises if this is not the correct forum for this, but I can't see to find anything specific to home chargers. I currently have a 9kW array and a Powerwall 2 and I'm now in the market for an EV since the company car is going back and the model Y is at the top of the list. So my question...

teslamotorsclub.com

 

[srs5694]

For grid-tied systems, I'm skeptical of the benefit of such a system. Consider this: In a grid-tied system, your solar power production is fixed in amount, in the sense that you generate X kWh of power on Day A, whether you charge your car on that power, use it in other ways, or are away from home and don't use it at all. When your generation exceeds your use, the power goes onto the grid and your neighbors use it. Thus, whenever you charge your car, you're putting extra demand on sources of electricity supply other than your solar panels; even if your car is being charged by your solar panels, you're denying that power to others, so demand on peaker plants goes up. Thus, you're not doing much to reduce the use of fossil fuels by this plan. (There will be some tiny line losses in exporting your power to your neighbors' houses, but that's about it.)

Trying to fit your electricity consumption to the output of your solar panels may smooth out changes in demand by a small amount, but if there are other home-based solar installations in your area, they won't all see exactly the same pattern of peaks and valleys at any given moment; they'll tend to even out when aggregated together, from the network operator's point of view. Thus, I'm skeptical that your plan will do any favors to your local utility on this score, either.

The considerations are different in a few rare areas, like parts of California, which have so much solar power generation that some of it's thrown away at peak production times. In those cases, it's best to do as much charging as possible when solar power production peaks. In this case, your system to reduce charging to match your production could be counter-productive; it'd be better to charge full-out at those times, so as to suck in as much of the production that would otherwise go to waste as possible, and avoid charging at night, when other (dirtier) sources of power would be used. AFAIK, though, this is a concern only in some parts of California, at least in the US.

There could also be billing issues in some cases; for instance, if you're paid less for power you export compared to power you consume from the grid, then your system might make sense. I don't claim familiarity with every billing system, but that's certainly not how it works here in Rhode Island. Likewise, time-of-use tariffs in conjunction with household battery storage could complicate matters -- but in most of those cases I know about, power is cheaper late at night, so you'd probably want to charge then, at least from an economic perspective.

 

[TS90D]

Saw this in the Tesla Parts for Sale forum about a powerwall:

Span Smart Panel — Span® | A Smarter Electric Panel

Do you think this could be a solution?

 

[holeydonut]

I also found this EV Charger from Emporia... I have their Vue home energy monitor, and their EV charger sounds cool too.

Emporia EV Charger White | Energy Star | UL Listed | 48 Amp | 24' Cable | 22

The Emporia EV Charging Station is a Level 2 electric vehicle charger that charges any EV up to 40 amps with NEMA 14-50P or up to 48 amps with hardwired installation. It comes with a 25’ cable with an SAE J1772 connector so it works with all electric cars.

shop.emporiaenergy.com

Once the charger is set to "standby"... according to their rep ... anyone with a common EV or PHEV (Tesla, Chevy, Volvo, etc) could plug in. And the Emproia Vue would instruct the vehicle to charge at whatever amps necessary to absorb the solar generation that would otherwise go past the meter.

The homeowner with this EV charger would also need a Vue energy monitor on the load side of the meter main. This is necessary since the Emporia Vue tells the Emporia EV Charger what solar output is about to backfeed the utility meter.



@srs5694, I'm in California... and there are two things shaping up that make an EV charging with excess solar important:


1) Solar customers pay a non-bypassable-charge (NBC) for every kWh that goes back to the grid. With NEM 2.0 (the current net metering), this is about $0.026 (two point six cents) per kWh. So pretend there's a home on average is generating 10,000 kWh per annum solar; of which 8,000 kWh is backfed to the grid to be used later when the sun sets. This example homeowner is paying 8,000 x $0.026 = $208 per year in NBCs. If instead 2,000 kwh is funneled into their EV during sun-up, there would be no NBC on this portion and the homeowner saves $52 per year.


2) Under the upcoming California net energy metering (NEM) 3.0, the NBC goes up about $0.01 per kWh. Plus, the CPUC is set to approve what amounts to a "solar tax" while simultaneously destroying the value of credits earned when a solar customer exports to the grid. The solar tax is currently proposed to be $8 per kWp AC per month. That means a 8 kWp AC solar system is "taxed" $64 per month ($768 per year) just to be permitted to export energy back to the grid. And, the proposal will drop the value of solar exports to the grid down to a new rate that ranges between only $0.04 per kWh and something around $0.10 per kWh near sun-down. There is no reasonable way the solar exports can offset the NBCs and $8 / kWp AC / month tax.

Adding all these factors together makes having a future solar system in California actually punitive to export to the grid. The homeowners in the Energy Subforum have been running numbers, and in all instances we've determined that under the proposed NEM 3.0... homes are better off with a solar array that generates energy ONLY to be used at that home (including stored in batteries at the home). The solar inverters and power control systems at the home would have to be intelligent enough to modulate down the solar production to make sure no backfeed to the grid. Said differently, the NEM 3.0 proposal is a motive for people to just not have NEM.

In summary, being able to charge an EV (or neighbors EVs) to prevent grid exports will be paramount in California very soon. While existing solar customers are grandfathered for a few more years, some of the early solar adopters are actually about to have their grandfathering expire once the new NEM 3.0 rules are put into effect. Those homeowners will either face the tough decision of either ripping out their solar, or finding alternatives to net metering.

 

[jgleigh]

AZ no longer has true net metering. My utility also doesn't offer TOU rates, so all my power is bought and sold at a flat rate. My sell price is about 1/2 of my buy price, so I use apps like ChargeHQ and scheduled charging to keep my grid usage as close to zero as possible.

My utility does have a $20/month flat fee, so selling back enough to cover that is still beneficial.

 

[DrGriz]

I downloaded ChargeHQ and ran it yesterday. Intermittent clouds during charging. I have a Fronius inverter and Tesla Powerwalls x 3 with a Tesla Wall charger.

The system ran flawlessly as far as I can tell. Tanked up the Powerwalls and then charged the car almost purely from solar, adjusting for the intermittent clouds until it hit my 70% target for the car. I then made a 3 kWh trip to town late in the afternoon, plugged it in when I got home and the system topped it off. According to TeslaFi, charged at 43, 7, 17 and 13 amps, but I could see on ChargeHQ that it was micro adjusting the amperage. No problems with crashing the Inverter, etc.

Yes there were intermittent spikes from the powerwalls due to sampling only every minute. I only pulled 0.2 kWh from the grid yesterday.

I have grandfathered into long term net metering, so there's no financial benefit for me to do this, only purity and bragging rights for solar only charging.

 

[DrChaos]

For grid-tied systems, I'm skeptical of the benefit of such a system. Consider this: In a grid-tied system, your solar power production is fixed in amount, in the sense that you generate X kWh of power on Day A, whether you charge your car on that power, use it in other ways, or are away from home and don't use it at all. When your generation exceeds your use, the power goes onto the grid and your neighbors use it. Thus, whenever you charge your car, you're putting extra demand on sources of electricity supply other than your solar panels; even if your car is being charged by your solar panels, you're denying that power to others, so demand on peaker plants goes up. Thus, you're not doing much to reduce the use of fossil fuels by this plan. (There will be some tiny line losses in exporting your power to your neighbors' houses, but that's about it.)

Trying to fit your electricity consumption to the output of your solar panels may smooth out changes in demand by a small amount, but if there are other home-based solar installations in your area, they won't all see exactly the same pattern of peaks and valleys at any given moment; they'll tend to even out when aggregated together, from the network operator's point of view. Thus, I'm skeptical that your plan will do any favors to your local utility on this score, either.

You're not wrong, but the utilities are in it for the money foremost, not for the kWh. They like EV's, but hate hate hate customer owned solar, not because it actually presents any major grid problems, but because it lowers their revenue. More and more utilities and regulators will be banning net metering and compensating for excess generation at minimal rates, while raising from grid rates.

So it will encourage people to do tricks like that to minimize grid consumption despite variable demand and generation.

SDG&E went even further in their horrible proposal, with penalty fees regardless of any generation, plus drastically reduce generation compensation. It would make nearly all customer owned solar uneconomical, even with a battery because of the grid tie fee.