Ideas thread for the Smartshift API

[madpilot]

Hey all.

Now that Smarshift is out of beta, and our data models are settling somewhat, I'd quite like to start thinking about what a Smartshift API could look like. I'd love to know what your use cases could possibly be.

[purcell-lab]

A couple of random thoughts.

It would be good to expose a number of elements around monitoring and controlling SmartShift.

Monitoring :

• current state of SmartShift - what commands is it currently issuing to the home (battery and inverter)
• forecasts for price, battery_soc, solar_generation and home_load could be exposed as you currently do with the pricing
• current tariff details
• details of what devices; battery, solar inverters, EV, ... are currently enroled
• binary sensor for cheapest and expensive times. e.g. like price spike but for the cheapest/ most expensive 90 minutes of day

Control:

• ability to change SmartShift mode; off, earnings_optimiser, battery_booster
• ability to switch control of individual registered devices into/ out of SmartShift
• ability to execute battery controls; charge, dispatch, preserve, consume
• ability to fine tune battery controls - e.g. export XXX W for next thirty minutes.

[dpretty]

It would be nice to be able to update the usage forecast via API (or perhaps this is something on the roadmap for the smartshift app?). At the start of the day I'll often have a pretty good idea of when and how long I'll charge the car for. I think currently smartshift is using the previous day's usage for the next day's forecast - which can be pretty inaccurate if I'm charging the car one day and not the other ...

[madpilot]

We'll probably tackle this as part of our upcoming EV work.

[rustyshelf]

This also goes beyond EVs. Lately when the price is negative all day in SA, I've been turning off my solar panels entirely...this really messes with the SmartShift's ability to predict what they heck is happening. Having some structured way to either reset or give the forecast some input would be nice.

[madpilot]

Noted. As always, it's not that simple, but we have noticed the same effect, and are trying to work out a solution.

[rustyshelf]

I bet, though I've found that often just giving the people that want it more control, solves a tonne of issues that algorithms might not be able to. These days I generally leave smart shift off, and occasionally turn it on just to give it some commands, then turn it back off when I'm done. I'd be over the moon if:

• You could use the SmartShift controls without turning SmartShift on (so I don't have to be around when a command ends to turn it off before it gets up to mischief)
• You could issue SmartShift really basic commands like "overnight, if the import price goes below $x, buy up to 11kWh" or similarly if the export prices goes above $y, sell up to this amount.

I think the two things above would give me everything I need out of it. I know it takes it away from being a magical algorithm that makes you money by itself, but I feel like a lot of your users must skew nerd/technical in the first place and the ones that don't can just leave it on and not go into the advanced settings?

[purcell-lab]

We'll probably tackle this as part of our upcoming EV work.

One thing I would like to see in the EV work is coordination. SmartShift is good and ChargeHQ is good, but currently they don't work well together, probably because they don't know what the other one is doing.

For example in ChargeHQ if I have battery priority and charging off excess solar everything works as expected, battery charges first and any excess after that goes into the EV, if SmartShift turns on grid services and starts charging battery ChargeHQ is OK. However if SmartShift starts exporting battery ChargeHQ gets confused.

Similar if ChargeHQ has EV charging priority and charging off excess solar everything is ok when battery is in self consumption mode, but if SmartShift starts charging battery (For example with low costs) ChargeHQ doesn't see that and maintains the EV charging so you can end up pulling additional power from grid, even if your excess solar was sufficient to charge battery and reduce EV charging.;

Being able to split excess solar; 50% battery, 50% EV would be useful.
Being able to charge EV at maximum charging rate e.g. during extremely_low prices.
Being able to charge EV at an average charging rate e.g. over a 4 hour negative FIT window.

The API aspects of this is the SmartShift API to be able to signal what it is doing - mode; charging, discharging, preserve, self-consumption and how much power it is seeking 3kW, 5kW, ... Then third party apps, such as chargeHQ or HomeAssistant could cordinate their activities with SmartShift.

[rustyshelf]

For me it's mostly what @purcell-lab said, I'd love to see:

• The current status of SmartShift (on, off, any manual or automatic things it's currently doing)
• The ability to send manual commands that mimic the 4 buttons in the app (charge battery, discharge battery, maintain charge, self consume)

As a stretch/wishlist item that's probably not possible:
A way to get SmartShift's current plan, and potentially send a different one in. With ability to access parameters like current price, etc. Eg:

• Between 12am and 6am, if there's more than %40 in my battery, and the export price is higher than 15c for the period, sell power
• Between 12am and 6am if my battery is under 70% and the price is negative, charge it

These would have to be ordered so there's easy conflict resolution, and the algorithm could execute them at whatever it's tick rate is. Eg: which ever action matches it's set of conditions gets executed for that period. I guess maybe 30m periods might make the most sense?

I already have a way to get all the stats on my battery via an API, but if you're going to design a general purpose API that works across batteries I imagine people will want that as well?

[wh0phd]

Really just want to set/unset any arbitrary thresholds, because right now the default is

• 0000-2359: ≤20% battery level: never sell at any price
• 0000-2359: >20% battery level: sell at any price subject to selected SmartShift mode

And I want to add overrides like:

• 1500-0900: >20% battery level: never sell below $1.00
• 0000-2359: >50% battery level: never sell below $1.00

In this example I would only over sell during price spikes, but still keep 50% for myself, unless it's daytime and want to go lower.

Further API enhancement could do better than times-of-day or non-DST-times-of-day:

• reference sunrise and sunset ± minutes
• reference peak production hours as a boolean ("is usually max") or just a threshold (e.g. "is usually 10kW")
• reference production hours as a ratio to average household load, e.g. solar is 1.0x, 2.0x, 5.0x of consumption

Honestly though, most people will just want:

• "target a daily minimum battery level of X%" … and
• "don't sell until price reaches X¢"
• "hard minimum of X%" is what we already have

[madpilot]

Do you want to do that via an API though? Or just in general? Are you thinking you'll dynamically set with those values?

[wh0phd]

Those last thoughts I had were not to do with API, sorry.

But just setting a timing schedule and price gates, I feel like we're only ever going to get API access to that, and any general settings are unrealistic. Am I wrong though?

[madpilot]

General settings aren't unrealistic (And we'd implement it that way before we allowed access via an API). Probably. I'll throw it in the product mix, and see what comes out.

[wh0phd]

Oh, right, that helps to know, even just that. Thanks!

[J-Rod-16]

This is a great idea, was wondering about it a few days ago actually.

I'd like to get the manual controls for my battery via an API so that I can link it to automations in NodeRed or Home Assistant. I understand Amber is already planning the charge/discharge sequence and reacting to prices but there may be times when I want to intervene, such as going on holiday or something unusual happening at the house.

I'd also like to get access to the charge/discharge, load and solar output forecasts via an API.

Cheers
Jarrad

[daniel-simpson]

Might be a pipe dream, but a huge one for me at the moment would be the ability to turn off battery export (Powerwall's "Go off-grid"). Not sure if it's an Amber or Powerwall thing though? Would be especially handy during negative Feed in Tariff times.

Either way, attaching that into Home Assistant would allow me to automate going "Off grid" so I don't have to do it myself each day (Feed in prices have been nuts the last few months in my area).

And thanks again for everything you've been doing. Seeking feedback this early must be frustrating, but hopefully pays dividends in the long run.

[daniel-simpson]

This would stop the battery from exporting to the grid, but not solar.

Really? Bugger! If I'd realised that I probably wouldn't have bothered on the Home Assistant piece 😞 Never mind, still a good learning experience.

What solar inverter do you have? If it's a Fronius or Sungrow you can probably do solar curtailment via modbus via home assistant

My inverters have "SOFAR solar" written all over them, so I'm guessing not 😭

[madpilot]

I asked around in here:

No, go off grid will simulate an outage. The solar will stop producing and the house will draw from the battery only. Once the battery runs down a bit, the solar will come back on, charging the battery and covering usage in the home until the battery is full. The solar will then shut off and you're back to battery only. This will continue while the battery remains in this mode and sun is up.
This is the reason it only works on single phase and with 5kW inverters - anything larger might trip the battery when more than 5kW is trying to go to the battery.

[purcell-lab]

For single phase the powerwall backs up the solar inverter, so when the power goes out (or off-grid) mode the inverter continues to operate and the solarpv is stored in the battery. As the battery gets full the powerwall gateway uses frequency control to tune down the solar production. After a while the battery gets below 95-90% the powerwall gateway uses frequency control to turn up the solar production. This is how powerwall can continue to recharge the battery indefinitely during an outage. Some amber customers are using this method during negative FIT.

For three phase solar inverters this doesn't work, as powerwall can only backup one phase, so in a blackout the inverter looses power to two phases and shuts down, no solar production and no recharging the battery during blackout. However when you take the powerwall offgrid (but no blackout) the solar inverter still sees power on all three phases and continues to operate, so continues to generate solar pv and exports it all to the grid as the powerwall thinks its offline. Even with three powerwalls (which I have) you are not able to simulate a three phase off grid network.

For the majority of users with a 6 kW panels, 5 kW solar inverter and a single powerwall the go off grid functionality is quite useful.

[daniel-simpson]

Ahh fantastic! I'm just a software dev, no way I was going to grab my multimeter and try and figure that one out 😰 ☠️

Great news that it'll be useful for some percentage of others,sorry I'm not able to help out with the three phase version but I'm guess it'd need inverter logic at a minimum too?

[daniel-simpson]

FYI for anyone following along, this is now live as part of the latest Home Assistant release and can be automated (for single-phase systems, same caveat as above).

Example automation for going off grid when prices are negative:

binary_sensor:
  - name: Amber Energy Negative Feed In
    platform: threshold
    entity_id: sensor.<YOUR SITE NAME>_feed_in_price
    lower: 0

  - name: Powerwall Almost Full
    platform: threshold
    entity_id: sensor.powerwall_charge
    upper: 95

automation offgrid:
  - id: power_automatically_go_off_grid
    alias: "Power: Automatically go off-grid"
    description: ""
    mode: single
    trigger:
      - platform: homeassistant
        event: start
      - platform: state
        entity_id:
          - binary_sensor.amber_energy_negative_feed_in
          - binary_sensor.powerwall_almost_full
    action:
      - choose:
          - conditions:
              - alias: "Negative Feed In && Battery almost full"
                and:
                  - condition: state
                    entity_id: binary_sensor.amber_energy_negative_feed_in
                    state: "on"
                  - condition: state
                    entity_id: binary_sensor.powerwall_almost_full
                    state: "on"
            sequence:
              - if:
                  - condition: state
                    entity_id: switch.home_energy_gateway_off_grid_operation
                    state: "off"
                then:
                  - service: switch.turn_on
                    data: {}
                    target:
                      entity_id: switch.home_energy_gateway_off_grid_operation
                    alias: Go off-grid
                alias: Go off grid, if we aren't already off-grid
        default:
          - if:
              - and:
                  - condition: state
                    entity_id: switch.home_energy_gateway_off_grid_operation
                    state: "on"
                  # Note: adding this second condition in case you have a grid outage while you're offline... Don't think it'll work anyway
                  - condition: state
                    entity_id: binary_sensor.grid_status
                    state: "on"
            then:
              - service: switch.turn_off
                data: {}
                target:
                  entity_id: switch.home_energy_gateway_off_grid_operation

Though if I'm being honest it feels very backward to curtail solar generation, after paying for panels and batteries 😭

[daniel-simpson]

[purcell-lab]

All good, I've spent a few hours digging in the powerwall local api and reckon I can put something together.

Do let us know how you are going, there is lots of interest in this.

Are you providing some updates to the powerwall local integration in Home Assistant?

[herbi3]

I guess this is already similar to other comments here, however I would like to see a simple power on/power off based on what smartshift is doing.

My specific usage is for my hotwater storage, this is currently controlled via shelly1pm device and is not connected separately at the meter so I can't use the already available smartshift for hotwater control.

[herbi3]

The ability of uploading our own data. Solar, grid, battery SOC, consumption. to have smart shift act as if everything was enrolled.

It would be great to have smartshift specify the charge or discharge duration. Solaredge inverters have remote command "timeout" - when the command is sent, after X seconds it returns to the default setting, therefore if the network goes down the inverter will still change revert to default at the end of the period.

This would give consumers the option to enable and disable smartshift by a virtual switch, and allows consumers to add in their own functions for certain events.

It would be great to have smartshift calculate an expected consumption rate based on previous data and have this available via the api.

customers could post the kWh total into Smartshift, where Smartshift does the calculation for energy and stores it. along with posting the current kW output as a live metric for what is currently happening, but not recorded anywhere since the kWh data would be available. optionally, to reset the kWh data, if new inverters etc. were added and suddenly the kWh total resets to zero, it would potentially show a massive negative metric within Smartshift if that were the case.

[madpilot]

Noted. We have spoken about this, so will be considered.

[rob0101]

I’d like to see Smartshift stop buying power based on speculation. It does that even in battery booster mode. It wastes money more than it creates revenue.

For the API, if you find something you can control in a battery API, just mirror it in yours, e.g. if you find a powerwall can be told to charge at a specific kw rate, then make it available. When features are manufacturer dependent, name them appropriately, e.g if only powerwall2 can charge at a specified rate, call it “powerwall2_charge_rate”.

Basically, expose as much control as possible.

In terms of features, things like “discharge for 30m” would ideally accept any number of minutes. If we could say when that happens e.g. “now” or “15:30”, it’d be even better.

Rates of charge and discharge would be very helpful. I often see my powerwall charging at 5kw but would prefer a slower rate. Smartshift seems to like 5kw, tesla prefers 3.7 for charging.

Time based SOC target rates would be very useful, e.g.
[{“at”:“13:30”, “min”:60,”max”:80},{“at”:”14:00”,”min”:70,”max”:85}, ….
That alone could form the basis of home made “plans” that can use far more inputs than available to Amber.

minimum smartshift sell prices and maximum smartshift buy prices are desperately needed in app and api.

those are the priorities for me. I hope some are feasible.

[madpilot]

This might be a good place to clarify my understanding about something. If at 3.01pm the price is 99c, and at 3.10pm it changes to 1c I don't think there's much point in stopping export until 3.30pm, because the price will end up being the average of that 30m period. So as I understand it if you exported 10kWh while it was 99c, you'll only get paid for whatever the 30m average was, not the 99c it was during that period.

Correct.

[rob0101]

Any update on when 5m billing kicks in ?. There are a lot of people in SA this morning with empty batteries because Smartshift couldn't be switched off once it was on a mission. It was very profitable, just hard to control.

[madpilot]

No updates, sorry. I'll let you all know when I know more.

[rob0101]

If at 3.01pm the price is 99c, and at 3.10pm it changes to 1c I don't think there's much point in stopping export until 3.30pm

it depends on your goal - maximise income or maximise supporting the grid and saving your battery for later. Things are setup to only do the former at this stage.

With everyone exporting until the end of the 30m, we're all adding unwanted power to the grid and forcing the average price ever lower.

[madpilot]

5 minute bug is fixed.

All current 5-minute intervals are now marked as CurrentInterval and the interval no longer disappears in the last 5-minutes of the 30-minute block.

[wh0phd]

I’d like to see Smartshift stop buying power based on speculation. It does that even in battery booster mode. It wastes money more than it creates revenue.

Pardon the tangent topic, but I think this audience will care about this: I find brownouts only impact while buying power, and presumably that applies to AC power quality, regularity, surges etc — things that delicate electronics prefer, or simply extend the life of power supplies. I'm presuming Tesla Gateway operates similarly to other brands, and this is why I agree with Rob.

I've disabled SmartShift since realising this. Revenue impact is only 25%-75% due to my two-way tariff.
I could actually see a great API for re-allowing power import when I am not at home.

[madpilot]

I'm not sure I follow?

[wh0phd]

(If this is OT we can take it to a new thread or DM) If you mean the last bit I said, I'm suggesting the same features as Rob (exact minutes, minimum buy/sell), but when I use them I'd build something to trigger via my location.

[rob0101]

Why would smartshift plan to sell from the battery during the day. The FIT will be 20c and soon after the buy price will be 20c again.
in battery booster mode this is really excessive activity that adds unnecessary wear to the battery.

[madpilot]

Smartshift models what it thinks your battery will do in self-consume mode (ie, when Smartshift is NOT in control) too so it can take them into account while optimising.

What you'd be seeing there is the battery covering the additional house usage that our forecast has predicted. In self consume mode, the house will prefer using solar, then battery, then finally the grid. The predicted solar levels are not enough to cover the predicted house consumption, so we predict the house will use some power from the battery.

It's a pretty sane strategy, given there is a bunch of solar to top up with later, and the battery would be full for the high price later, so no reason for Smartshift to intervene and override.

[rob0101]

I believe the powerwall would have been in Time Based Control mode, which never draws from the battery during solar sponge.

Discharging from the battery during solar sponge hours is almost always the wrong decision for my usage. The exception would be a very high spike happening and “battery booster” choosing to participate.

smartshift trying to predict my demand will almost never work. It can’t know if the EVs will get a top up today. My automations respond to prices and never to my solar output which is mostly dwarfed by my consumption.

This is why having smartshift be controllable by customer inputs is so useful.

[rob0101]

Just re-reading your reply. Is the dip in battery SOC in the plan your system thinking battery will be used rather than it planning to "dispatch" some power from the battery ?

If it's the former, that's interesting and useful, but the graph needs some way to tell me this is not a smartshift planned action.

Basically we need a distinction between predicted and planned battery SOC changes.

I read that there used to be a distinction for recent activity. That should be restored too and that way people might stop blaming smartshift for doing things it had no involvement in.

[madpilot]

Just re-reading your reply. Is the dip in battery SOC in the plan your system thinking battery will be used rather than it planning to "dispatch" some power from the battery ?

Correct.

I read that there used to be a distinction for recent activity. That should be restored too and that way people might stop blaming smartshift for doing things it had no involvement in.

It's planned, just not sure when yet.

but the graph needs some way to tell me this is not a smartshift planned action.

Good point. I'll add it to the notes for the history work

[herbi3]

@madpilot gidday, is there any roadmap so far for when or if a smartshift api would be available?

[madpilot]

Looking like Q3 at this stage, but as with all these things, that may change.

[rob0101]

In recent weeks I've realised that it'd be really useful to have a setting (in cents per kWh) that told smartshift to use grid power if the buy price is at or below that value.

As a default it could be set to 0c so that everyone uses free or negative electricity.

I'd probably set mine right now at 10c so that if the price drops that low overnight, things like a HWS could turn on and not draw power from the battery (saving the battery for later). Others might do something similar with an AC unit to heat the house.

Currently in the middle of the night I can turn on the HWS at <=10c but it starts using the battery, which is not what I want.

In the warmer months I'd reduce the 10c down to near zero.

[konstar]

I would like to set my minimum reserve. I'm constantly shifting my reserve via based on weather forecasts, and having to jump to the App to tell SmartShift.
E.g. 15% baseline, 50% reserve if there is a storm, 5% reserve if it is morning and Sun predicted soon.

Would it help if we provided SmartShift with information about my planned load for the next 24 hours? Could it make better forecasts about what to do?
E.g. My weather forecasts that outside temperature will dip < 10C at 10AM, so I'll be running AirCon which will initially consume 6kW between 9 and 9:15 AM, then drop to 1kW / hour. So I know there will be a bump in my expected load. Therefore, an optimal solution might be to charge the battery by 4 or 5kWh during low general price in advance so it could draw from battery.

[madpilot]

Please don't mess with your MRL unless you change it in BOTH the Amber and the Tesla apps.

We are working on something will probably do what you are TRYING to do, and that will probably be controllable by the API

[konstar]

Yeah, I try to keep Amber's MRL in sync with battery reserve. But it's getting old.

Thinking about it further, instead of an API, is it better to just poll it from the battery if that's possible? I didn't look like the REST API from SolarEdge exposed reservation levels - so maybe it's not that easy?

On the 2nd point I mentioned - I guess it could be summed up as - what do you need from users to help the SmartShift team make a better plan? Maybe it could take the form of:

• Exposing the predicted load consumption for the next 24 hours.
• Allow users to tweak the predicted load consumption so the SmartShift plan optimises along with all the other parameters that are out of users control.
• If there is a financial incentive for Amber to predict load, then maybe that could be shared with users as a reward who accurately predict their load within some margin of error?

[brodykenrick]

This is echoing what a few others have said, but I would like the API to be extended with:

• Extend the price forecast for general usage and FiT over a week (rather than just 24 hours)
• forecasts for the smartshift "plan" with Battery SoC, any planned charge/hold/discharge actions, predicted solar and predicted load could
• Share the simple smartshift explanations for the site - e.g. "You're green charging". My wife likes those straight-forward explanations of what the plan/house is doing at the moment

[herbi3]

gidday @madpilot - if we would be able to post our own instantaneous kW rates (current consumption, import or export) etc. collectively, could it also be possible to post into the API our battery/backup reserve setting.

with solaredge inverters, I am able to dynamically change the backup reserve setting via modbus. Currently, when a price spike hits my area, my scripts change the backup reserve setting from 20% down to 5%. this prevents us from buying expensive energy and it also allows us to discharge our batteries even further during a spike, where we otherwise wouldn't be able to.

I understand the API is a while off yet, but I would love to have the ability sooner rather than later to use the smartshift API so I can unenroll my inverters from solaredge VPP. Solaredge servers just aren't reliable enough in terms of response time, and it would be great to not have certain enrolled settings to be changed back to the VPP default every 30 seconds.

The VPP defaults back after 30 seconds if I manually override the current settings, like when FiT prices are negative and the inverter sometimes does not get the command from VPP to initiate curtailment (Amber may have sent the command, but the solaredge servers seem to not submit the command to the inverters occasionally, like today)

[madpilot]

Unfortunately an API to enrol and unenrol from the SolarEdge VPP is not possible. It's actually a manual human process (which is why it takes so long).

There isn't an API on their end to do that.

I don't think there is a minimum reserve level API, either (though that is from memory).

The other stuff is a possibility, but I don't have timelines right now.

[herbi3]

Thanks @madpilot apologies, I am directly talking about the potential amber electric smartshift api and related functions.

Directly to the solaredge inverters, I am currently changing the reserve level dynamically and automatically via tcp modbus. However, I wish to update amber smartshift settings with the new reserve setting when it changes (otherwise amber only knows the manually set value, and I wish to push the actual reserve setting into amber api)

If my batteries right now are at the minimum reserve setting and a price spike hits right now, then usually I would be forced to buy at the import rate.

But, since I am already dynamically changing the reserve setting directly and locally to the inverters via tcp modbus, I am able to lower the reserve setting from 20% down to 5% - this is what I have automated already, but I wish to now update the settings in amber via the amber api, specially the potential smartshift api.

[petehhhhh]

I simply want to be able to manually control the battery via the API and be able to check status of these controls. I can then program the rest of my use cases around this. From the thread I gather this is in the works. When do you expect to have available ?

[rob0101]

Feature request: With historic data, can we have 4 new items:

1. kwh smartshift bought to add to the battery (in total)
2. kwh smartshift bought specifically for a forecast price spike.
3. kwh smartshift sold to the grid.
   These would be specifically for smartshift initiated actions.
4. battery SOC at the end of 30m.

Thanks.

[daniel-simpson]

After thinking about this for ages in the back of my mind, I really only want a few super simple commands, everything else is another automation layer on top of them:

• turn off smartshift (analogous to self-consumption in the Tesla app)
• charge powerwall up to X% (defaults to 100)
• export powerwall down to Y% (defaults to minimum reserve level)

Everything else about scheduling, time of use, etc could all just be handled by something else (in my case, home assistant and or the Tesla app's minimum reserve level).

Ive already got the first two points hacked together with a HACS Tesla add on, but the ability to switch to exporting power via api would be huge. And hopefully relatively simple compared to some of the (great but complex) suggestions above

[rustyshelf]

After living with SmartShift for a decent while, I think I've come up with a much simpler API I'd want.

A way to have SmartShift not make any plans and just run in self consume mode 24/7 with the following 4 APIs:

• charge for [X mins]
• discharge for [X mins]
• during [time range] if power is less than [X cents], buy as much as you can
• during [time range], if power is above [X cents], sell up to [Y%] of my total capacity.

If there was a way to do the above I'd be set.

[madpilot]

1 and 2 seem like the most likely implementation (with the ability to delay start time).

3 and 4 would probably be left as an exercise for the reader - if you are capable of utilising the API, you are probably capable of implementing that logic.

[rustyshelf]

Sounds great. As long as there's a way to have SmartShift not do anything on its own I'd be happy. The other day it was buying power at $6 per kWh and nothing I did got it to stop.

[sentience]

I'd mainly like the ability to switch on/off Automatic Solar Curtailment programmatically via the API.

My use case is that I have a "solar-aware" EV charger (myenergi Zappi) that cannot see my DC-coupled home battery. It can only monitor grid import/export. To prioritise charging the home battery over charging the car battery, and to avoid charging the car battery from the home battery, the EV charger is configured with an "export margin" of 100W, so it will only charge the car if it sees 100W or more being exported to the grid. It continually adjusts its charge rate to keep that export margin.

Automated solar curtailment messes with this setup, since it prevents exports during times of negative feed-in prices. I would therefore like to disable curtailment whenever my car battery is <100, and my car is plugged in at home.

(Alternatively, if Smartshift's curtailment could also be configured with an "export margin", say to allow 100W of export during negative feed-in prices, that would also solve my problem.)

[danielclau]

I would just love to be able to turn Smartshift On and Off via the API so I can automate it in Home Assistant.