General Integration Questions

[HarryFlatter]

I'll kick it of with....

1. The select.mg_hs_phev_trophy_scheduled_charging_mode has 2 values; Disabled and Until Scheduled Time.

Could that actually read Disabled - meaning if I hit the charging button (switch.mg_hs_phev_trophy_charging), charging will start immediately assuming binary_sensor.mg_hs_phev_trophy_charging_gun_state is 'Plugged In'
OR Enabled - meaning if I hit the charging button (switch.mg_hs_phev_trophy_charging), charging will start assuming binary_sensor.mg_hs_phev_trophy_charging_gun_state is 'Plugged In', but limited to the times set in time.mg_hs_phev_trophy_scheduled_charging_start and time.mg_hs_phev_trophy_scheduled_charging_end entities.

2. This regards the heating. I just wanted clarify how this works. If I set the time.mg_hs_phev_trophy_battery_heating_schedule_time and then hit the switch.mg_hs_phev_trophy_battery_heating switch, then battery heating will take place every day at that time? Are there any other conditions that need to be met for the switch to work? Whenever I've tried it, it bounces back to off after a short while.
   Also, what switches the heating off? Does the sensor.mg_hs_phev_trophy_battery_heating_status sensor show the state of the switch or whether the heating is actually active?

3. Port Lock. On the basis that the car / charging process pretty much takes care of locking/unlocking or the cable port, do you think this entity is much use? Maybe as a status, but even then I'm not sure. Am I missing anything here?

Thanks James👍

[townsmcp]

Thanks Harry — good questions. Taking them in turn:

1. Scheduled charging mode ("Disabled" / "Until Scheduled Time")

Your reading is essentially right. The select maps to SAIC's own scheduling mode:

• Disabled — no scheduling constraint. Hit the charging switch (with the gun Plugged In) and it charges immediately.
• Until Scheduled Time — charging is constrained to the window you set in the scheduled-start / scheduled-end time entities.

There's a third value, Until Target SOC, that some cars expose and yours doesn't — which is why you only see two. The labels come straight from what SAIC reports, so they reflect the car's behaviour, not a naming choice on our side.

2. Battery heating

Two separate things here, which is the source of the confusion:

• The plain battery heating switch is immediate manual heating. Its on/off state is driven by the car's actual bmsPTCHeatResp value from the charging data (1 = actually heating) — not by whether you pressed the button. So when you toggle it on and the car doesn't actually begin heating (battery not cold enough, or the conditions the car requires aren't met), the next poll reads "not heating" and the switch flips back to off. That's the bounce you're seeing — the switch is honestly reporting that the car didn't start heating, rather than latching your press.
• The battery heating status sensor reads the same bmsPTCHeatResp field (0 = Off, 1 = On, 2 = Error). So it shows whether heating is actually active, not the switch position.
• The schedule (schedule switch + schedule-time entity) is the separate "do it daily at this time" mechanism — distinct from the immediate switch above.
• However the most impoart at the moment though is its just to hot - see my post here [ISSUE] HVAC strange behavior and wrong state #243 (comment)

So to answer directly: yes, there are conditions beyond just flipping the switch, the car decides whether to actually heat, and the status sensor reflects real activity rather than the switch state.

3. Port Lock

Fair assessment. The car manages port locking/unlocking itself during the charge cycle, so as a control it's rarely needed. Its main value is as a status, plus the occasional manual override (e.g. releasing a cable the car has left locked). If you find it more clutter than use, it's safe to just hide the entity — nothing else depends on it.

Thanks, James 👍 — happy to spin any of these out into an issue if they turn up something worth changing.

[HarryFlatter]

Clear thanks James, apart clarifying a couple of things

1. For my car, I will map the charging schedule mode to Disabled and Enabled
2. The battery heating status sensor reads the same bmsPTCHeatResp field (0 = Off, 1 = On, 2 = Error). So it shows whether heating is actually active, not the switch position. Although I guess the 2 are linked in that if the switch is latched the status will show 1 and probably 2. If the switch is unlatched the status will always be 0.

3. On Heating: The schedule (schedule switch + schedule-time entity) is the separate "do it daily at this time" mechanism — distinct from the immediate switch above.
   Confused. I can only see 3 heating entities; On/Off toggle, start time, heating status. What is this schedule switch of which you speak😜

[HarryFlatter]

I was and will work on that basis. You pretty much confirmed what I was thinking.
As and when I get around to doing a test - I will report back.

[townsmcp]

No worries, test whenever you are ready

[townsmcp]

Also, take a look at the latest HA release, specifically https://www.home-assistant.io/blog/2026/08/05/release-20268/#your-entity-ids-your-choice

[HarryFlatter]

Well that got you off the hook😁
That will obviously sort the 'area' problem. Do you reckon it will stop the 'double' device issue, ie system derived device name prefixed by device name set up by the user when integration is first loaded?
e.g.. binary_sensor.outside_mg_hs_phev_trophy_mg_hs_super_hybrid_window_front_left

[townsmcp]

I think it will sort that as well. If you want the short clip on that page they show the combination you can set it to. I think it is a good supplement to the way things work and certainly having more control is just what was needed - I have done the update but not delved into this naming convention yet.

By the way, thank you so much for the BuyMeACoffee! It is much appreciated

[HarryFlatter]

Morning James!

I was happily coding away until around 2am and decided to call it a day/night. Car was charging and all seemed to be OK, apart from a persistent invalid interior temp sensor reading of -128.

On returning to my laptop, whilst SOC was 100% it said it was still charging. Then I noticed the time of the last update was 03:06. It seems that around this time the charging completed, but some weird stuff started happening and I got no further updates to say Charging Complete or Connecting which is what it usually says once the charging session has complete. See screen shot from 09:10ish and you'll see it still says last update was 03:06 and despite 6 hours passing, the 09:06 refresh time came and went with no activity. At 09:18 it did get around to doing something and got a bunch of errors relating to charging info. Error 4s amongst them. Reachability still Awake and freshness still Live.

Something happened a 03:06 to kick all this off, but no idea what.

The attached log is not MG filtered I'm afraid as I had to download it to see it.

I'm now going to go and disconnect the car to see if that changes the charging info status and will report back.

home-assistant_2026-08-07T09-02-12.684Z.log

[HarryFlatter]

PART 3
Disconnected the car and 'fired' it up. Shut down, locked it. Also did a refresh which again timed out.

Reachability still Awake and freshness still Live.

MG-SAIC Log - Cable Disconnect-Car Start-Data Refresh.txt

[HarryFlatter]

PART 4
I think I've gone as far as I can in this session. Something (car or SAIC server) is preventing the charging info from coming back.
Now going to restart integration. It won't fix charging info (iSmart also still failing), but it will give me a clean base to work from.
What the Sam hell happened at 03:06??

MG-SAIC Log - Integration Restart.txt

[townsmcp]

Hi Harry. I’m not ignoring you on this, but I will take a look into it soon. I have a few other bugs that have cropped up that I am trying to squash at the moment. Potentially some of these issues might be squashed as part of that investigation

[HarryFlatter]

No probs.

[HarryFlatter]

Just an update, as of 19:52. I still have comms with the car, but the failure of charging data that started at 03:06 this morning persists.
iSmart also timing out on charging data, but interestingly it can get the the SOC, whereas it's not available to the integration.

[townsmcp]

@HarryFlatter
Right, dug into all four logs — thanks for the blow-by-blow, it was exactly what I needed. Splitting it into what's yours-to-worry-about vs mine:

The core problem is SAIC-side, and your own testing proves it. Charging-info retrieval has been failing (return code 4 / timeout) since ~03:06, and — the key tell — the iSmart app fails on charging info too (it gets SOC but not the charging data). When the official app can't fetch it either, it's the car or SAIC's servers, not the integration. Ours is correctly surfacing the failure (the error-4s and retries) and keeping Reachability/Freshness green because the rest of the data is fine. Nothing to fix there beyond waiting for SAIC/the car to start answering again.

But your logs exposed three things on my side that I've now fixed (landed in 1.2.0-beta11):

1. A failing charging fetch was holding up / aborting the whole refresh. At runtime it wasn't time-capped and re-raised on failure, so it burned ~45s of retries and then failed the entire cycle — which is why your manual refresh timed out. It's now bounded and non-blocking: the rest of the data comes through and charging just shows its last value until the endpoint recovers.
2. The missed "Charging Complete / Connecting". When charging finished at 03:06, that transition wasn't being treated as activity, so with your 6-hour idle interval the next poll wasn't due until ~09:06. It now re-checks promptly after a charge stops (or the endpoint drops out), so you'll get the completion update.
3. The -128 interior temp — now rejected (along with other out-of-range junk) so it won't display.

Separately, I also found and fixed an unrelated bug where a "vehicle started" push could record the power-on time up to ~2 hours in the future (a timezone mismatch in the SAIC message) — that's in beta10.

So: the charging outage itself is SAIC's to resolve, but the integration will handle it far more gracefully now. Give beta11 a go once it's up and let me know if the refresh behaves better next time the endpoint has a wobble.

[HarryFlatter]

Thanks James. Updating now and will test when I can. We're away for the weekend, so I'll probably have a better look on Sunday evening.

Out of interest, what do you think of my dashboard front page?
At some point I will upload a video of it and its numerous popup pages to the MG forum thread.
This is all your fault - the hours I spend on this 😜

[townsmcp]

Hehe no worries. I am away for the weekend as well from the morning.
I really like the dashboard. Looks great. Looking forward to seeing more of it

[HarryFlatter]

Final update before weekend...
Car started charging at 00:30, on schedule. It only had a small fill to do.
Once charging started, the car started to report charging again! Yay, I thought. Joy was short-lived because as soon as it got to 100% SOC, it stopped responding to your charging poll and now its stuck again!!

2026-08-08 01:22:13.903 WARNING (MainThread) [custom_components.mg_saic] Charging info did not return within 20s for VIN LSJW94399TG046986 — proceeding without it; will retry on the next update

The good news is that the integration is not getting glued up waiting for retries and the outage is handled much more elegantly.
See attached log of when it all goes PT again...
MG-SAIC Log - Charging Outage.txt

[townsmcp]

That log is exactly what I wanted to see — thanks. All three of the beta11 changes are doing their job in it:

• Charging info did not return within 20s … proceeding without it — the fetch now bails cleanly instead of burning retries and dragging the refresh down.
• Charging stopped/dropped … flagging activity → Within grace period … 0:10:00 — so instead of disappearing until the next 6-hourly poll, it's now re-checking every 10 minutes after the charge drops.

On the outage itself: your log shows the SOC climbing to 100% and then the charging fetch timing out — the car's charging endpoint goes quiet the moment the session completes. With the iSmart app failing on the same data, that's the car/SAIC side, not something the integration can force. But it's now handled gracefully rather than gumming everything up, which was the goal.

So: the outage is SAIC's to sort, but your car's the reason this got properly robust — genuinely appreciate the testing. Have a good weekend, and shout if anything else crops up. 👍

[HarryFlatter]

Idiots guide to Air Conditioning

Apologies if you have covered this James.

When I very first started with this integration, I think there was only one AC control:

climate.mg_hs_phev_trophy_climate - Which typically used the standard HA thermostat card. I could control the AC using this, but wasn't sure how to implement that into custom buttons on my dashboard.

More recently I spotted the addition of:

select.mg_hs_phev_trophy_climate_mode
number.mg_hs_phev_trophy_mg_climate_target_temperature
switch.mg_hs_phev_trophy_air_conditioning

These entities are much simpler to use with custom buttons.

So my question is, is there a right or wrong way to control the AC?

Intuitively, I would use the 3 separate entities, set the mode, set the target and switch it on.

Once the target temp is reached, does the AC switch off or does it idle, maintaining the temp?

[townsmcp]

No, there is no right or wrong way. They all use the same underlying API commands - its just an adidtional way of showing those control points individually. The new discrete control entities were primarily implemented to allow controlling climate from voice devices (Alexa, Google Home etc) but are open to be used however you want - seems like dashboard use is a good usecase for them.

lol i couldnt tell you what happens after the car reaches the target temp - its been so hot since I have had the car that it hasnt reached my set temps I have sent! I would assume it switches off the AC though

[HarryFlatter]

Thanks James.
I just did an experiment. I set temp to 24 (currently set to 22), set the mode to cool and before I could switch it on the AC started all by itself. I presume that the mode setting fired this off. When would the switch be of use if you simply set the mode to off cool or fan?

I checked iSMart and it concurred that the AC was running, but disagreed on the target temp. Still said 22, despite my setting of 24.

The major issue is that I could not turn it off!. Switch kept flipping back to on and mode flipped back to Cool.

Oooerr, then I checked the logs....

AC Log 1.txt

[HarryFlatter]

PS - I did repeat the test and the result was the same.

[townsmcp]

Yep, mode would have fired the AC up - same as in the climate device - if you set a temp and then change the mode, mode actiates the cars climate controls. Always set a temp first (unless you are happy with the temp setting already) - this all goes back to the 3 commands ceiling until the car is next restarted by key and trying to save commands.

Target temp from/to iSmart is not something that tallies up - when you fire climate from iSmart HA doesnt adjust its temps as the target temp is simply missing from the API so we never get to see it. And vice versa, iSmart cant read what we have set the target temp to be so the app doesnt update to our climate command.

On not being able to turn it off — I checked your log and it's a SAIC server hiccup, not the integration. The OFF command came back with a 500 error from SAIC's /vehicle/control endpoint ("Error stopping AC … return code 500"), so it never actually reached the car and the AC kept running. The switch and mode "flipping back to on/Cool" is the integration doing the right thing: it shows off optimistically when you tap it, then the next poll reads the car's real state (still cooling) and snaps them back to match — they weren't disobeying you, the car genuinely never turned off. A 500 is normally a transient wobble on SAIC's side.

[townsmcp]

Why HA can't show the AC target temperature — proven with two tests

Harry, this bugged me enough that I went and proved it properly rather than just asserting it. Short version: the target temperature you set is sent to the car in the command, but the car never reports it back in any status response — so there's genuinely nothing for the integration to read. Here's the evidence from two separate tests.

Test 1 — decrypted the app's own network traffic

I ran a proxy (mitmproxy) that decrypts the iSmart app's encrypted API calls, then set the temperature to 19°C in the app and sent the AC-on command while capturing everything.

The outbound command does carry the temperature. The AC command (POST /vehicle/control, rvcReqType: 6) contained a parameter paramId 20 → [5] — index 5, which is exactly 19°C in the car's temperature scale. So the app sends the setpoint, and our integration does the same thing when you set a temp and fire the AC.

But the inbound status response does not. The response the app polls (/vehicle/status) is a completely different shape — it only reports the climate state as a single field, remoteClimateStatus (0 = off, 2 = cooling). There is no temperature-setpoint field anywhere in it, and there's no separate "climate" endpoint that returns one either. The paramId 20 / index 5 appears only in the command that goes out — it's absent from every reply that comes back.

Test 2 — my live Home Assistant log, same moment

To confirm the integration sees the same thing, I watched HA's live log while doing the above. Two consecutive fetches, before and after the AC came on:

• AC off: remoteClimateStatus=0, interiorTemperature=51, exteriorTemperature=-128
• AC on: remoteClimateStatus=2, interiorTemperature=51, exteriorTemperature=40

The only climate value that changed when the AC started was remoteClimateStatus (0 → 2) — which is exactly why the integration correctly flipped the switch and mode to on/Cool. There is no 19, no 5, and no setpoint field anywhere in the data. (A neat extra proof: the generic extendedData1 field read 78 both before and after — so nothing hidden shifted to reflect the 19°C either. And the 5 you might spot in the charging data is bmsOnBdChrgTrgtSOCDspCmd, the charging SOC target — nothing to do with the AC.)

Why the setpoint isn't in the response

The car's telematics reports the climate state — is it on, and in what mode — but not the setpoint it's running at. The temperature you choose only ever exists in the outgoing command; once sent, it's not echoed back in any form. This is the same in both directions, which is why iSmart showed 22°C while HA had a different value, and why HA can't reflect a temperature you set in iSmart: neither app can read the other's setpoint, because SAIC simply doesn't put it on the wire.

Bottom line

It's not that we forgot to wire the target temp up to the car — there's nothing to wire it to. The integration reads the climate state (which it uses correctly), but the setpoint isn't in any response, so the only value it can ever show is the one you last set from HA. That's exactly what the number...._climate_target_temperature entity already does. It's a hard SAIC platform limitation, confirmed both on the wire and in HA.

[HarryFlatter]

So thorough as ever - thanks James.

I always leave my AC on Auto and set to 22deg. Having hit the command limit before my next test, I popped out to the car for a key start and noticed that the AC was set to manual (fan 6) and 'Lo' temp.

I wonder how that happens, or whether it is some default setting when it receives a remote AC command.

Since the mode activates and deactivates the AC, is the switch.mg_hs_phev_trophy_air_conditioning, actually surplus to requirements?

Just tried another 2 tests. Set the temp, selected 'Cool' and it fires up immediately. However, any attempt to shut it down consistently comes back with an error 500. Stopping it with iSmart (which when refreshed recognised that the AC was running) works 100%. So the iSmart command is definitely working.

I can also confirm that AC is set to manual (fan 6) and 'Lo' temp each time I send the remote command. It would appear to ignore the setpoint completely.

Is it possible that different models have different command structures?

[townsmcp]

I think I have observed similar - I leave my car on Auto as well when in it and I think when I get back in from having sent commands from iSmart or HA it usually takes the Auto off as well. Maybe try doing a remote climate from iSmart and see if you observe the same? Interestingly the previous car (Mazda CX-60) always had the Auto climate turned off by their app and HA even though I always preferred Auto for fan control (although their version of Auto set the fans to always be directed at feet to heat/cool the battery rather than directing the fans facing the driver/passenger to take priority, it was very strange.

I think switching AC on is actually not really needed if you intend on changing mode/temp etc. but if you always use the same setting, it’s just as easy to use. I think there’s no really benefit either way now that we have broken controls down as well as the climate entity.

That’s strange that the ismart app is working 100% of the time to turn off.

Yep, 100% I have seen different models have their own command sets -especially newer model cars compared to older ones. I’m sure I have a guided test steps on here somewhere to be able to obtain logs for specific vehicles. This may also be why Off isn’t working for you? I can’t remember what model you have - check the README to see if your model is one of the listed climate specific types I have coded for

[HarryFlatter]

Mine is HS PHEV Trophy.
Would it be possible for me to capture the iSmart stream so that you could identify if there is a further variant on the AC command set.

[HarryFlatter]

OK some more testing with iSmart.
On my version (HS PHEV) of iSmart, I have 2 seperate climate controls. Apart from straight AC, I also have something called AC Airflow.

AC Airflow has no settings, just on and off and it set the climate control from Auto 20 deg to this:

Switched off OK and left settings in place

AC has temperature setting and on/off. Setting temp to 24 (auto-started AC without needing to hit the 'On' button) set the climate control from Auto 20 deg to this:

Switched off OK and left settings in place.

Switching on AC from HA sets climate to manual AC, Fan 6 (out of 11) and 'Lo' for temp.
And as noted, switching off AC fails persistently.

I'm guessing that the HS PHEV has a different command set for AC on and probably likewise for AC off. There may also be an undiscovered command set for AC Airflow on/off too

[townsmcp]

This is really useful testing, Harry — you've isolated something real. Let me split it into "expected" vs "genuinely worth chasing":

Expected (and not fixable from our side):

• Reverting to manual / losing Auto. The remote climate command — the one both the integration and iSmart send — is a basic one: on/off, a temperature, and a preset fan. It can't put the car into "Auto"; the car drops out of Auto whenever it receives any remote climate command. So HA can't preserve or set Auto, and it doesn't expose a fan/mode control, because the remote API isn't the same rich interface as the in-car climate panel.

Genuinely worth chasing (an HS PHEV command mismatch):

• The tell-tale is that OFF fails every time from HA but works 100% from iSmart — and consistently, not randomly. That rules out the transient SAIC 500 I mentioned before: if iSmart's OFF always works, the endpoint's fine, and it's our OFF command that the HS PHEV doesn't accept. The setpoint being ignored (fan 6 / "Lo" every time) points the same way — the on-command params probably aren't what your model expects either. And your "AC Airflow" control is a separate command we don't implement at all.

So yes — capturing the iSmart stream is exactly the way to sort this. If you grab the decrypted traffic while doing a few specific AC actions, I can see precisely how the HS PHEV encodes AC-on, AC-off, and correct our command set for your model (this is how the newer S-series cars got their own climate profiles). However getting mitmproxy working is a real pain. It can all be captured via HA live logging though. Steps below.

[townsmcp]

Capturing the AC command data

Two ways to grab this — ideally do both, because they capture different halves: the HA log shows what the integration sends (and exactly where the OFF fails), and the iSmart capture shows what your HS PHEV actually accepts. The HA log is the quick one; the iSmart capture is what lets me build the correct command for your model.

---

Option A — Home Assistant debug log (quick, no extra tools)

This captures what the integration sends and the errors it gets back.

Turn on debug logging. Add this to configuration.yaml (or extend your existing logger: block):

logger:
  default: warning
  logs:
    custom_components.mg_saic: debug
    saic_ismart_client_ng: debug

Then restart Home Assistant (or reload the logger from Developer Tools → Actions → logger.set_level if you'd rather not restart). The saic_ismart_client_ng line is important — that's the underlying client, and it logs the actual command being sent to SAIC.

Do the actions, noting the wall-clock time of each (leave ~20s between them):

1. Set the target temperature (e.g. 24 °C).
2. Set the mode to Cool (this fires the AC on).
3. Turn the AC off (this is the one that 500s — we want it in the log).
4. If you have the AC Airflow toggle exposed in HA, try that on/off too.

Grab the log: Settings → System → Logs → "Download Full Log" (the downloaded file has the DEBUG detail; the on-screen view often doesn't). Send me the lines mentioning mg_saic and saic_ismart_client_ng around those timestamps.

What this shows me: the temperature index and fan speed we calculate, the exact command we send, and the precise failure on the OFF (return code: 500 … /vehicle/control).

---

Option B — iSmart traffic capture (definitive — the correct commands)

The app encrypts its request bodies, so a plain proxy capture won't be readable — you'll need the decrypt add-on I use (I'll send it to you). Then:

Set-up (one time):

1. On a computer on the same Wi-Fi as your phone, install mitmproxy (pip install mitmproxy).
2. Put the decrypt add-on I send you in a folder and start it: mitmweb -s saic_decrypt.py (mitmweb gives a browser view; mitmproxy -s … is the terminal version).
3. Note your computer's local IP (e.g. 192.168.1.50).
4. On the phone's Wi-Fi settings, set a manual HTTP proxy → that IP, port 8080.
5. On the phone, open a browser to mitm.it, install the mitmproxy certificate and trust it fully:
   • iOS: install the profile, then Settings → General → About → Certificate Trust Settings → enable it.
   • Android: install under user certificates (some Android setups need extra steps to trust user certs).
6. Open iSmart and confirm traffic is flowing (you'll see gateway-mg-eu.soimt.com entries).

The capture (distinct actions, ~20s apart, note the time of each):

1. Start with climate off.
2. AC on with a set temperature — e.g. 24 °C.
3. AC off.
4. AC Airflow on.
5. AC Airflow off.
6. (Optional) send a different temperature (e.g. 19 °C) so I can confirm the temp mapping.

Sending it to me:

• I only need the POST …/vehicle/control request bodies (the rvcReqType / rvcParams blocks).
• Please redact or drop the blade-auth and app-verification-string headers before posting — those are your account tokens. The request/response bodies are the safe, useful part.

---

Why both: Option A shows me exactly what our command looks like and confirms the OFF failure; Option B shows me what your car expects for on, off, and Airflow. The difference between the two is the fix — I can then add an HS-PHEV command profile the same way the newer S-series cars got theirs.

[HarryFlatter]

I will give this a shot today James.
For option A where you say...

If you have the AC Airflow toggle exposed in HA, try that on/off too.

How would I have that exposed in HA other than in your integration?

For option B, have you sent me something (decrypt add-on)?
Can this be done on a Windows 11 laptop? I'm not a Linux bod, I'm afraid. HA just runs on a Widows 11 mini PC inside a VM Workstation Pro 17 VM.

[townsmcp]

I am not sure if you can do it on Windows - I have it running in a docker container on Linux - I guess you should be able to put it in a docker container in Windows.
Details can be seen https://github.com/townsmcp/mg-saic-ha/tree/main/tools (including the script) if you want to go down the route of trying mitmproxy - word of warning though is it can be a pain in the butt to setup. I ended up using ChatGPT for help initially get it going

[HarryFlatter]

I'll do the easy bit first and report back.👍

Re the AC Airflow toggle, how would I have that exposed in HA other than in your integration? Is it an API call you recognise?

[HarryFlatter]

Hi James, I've got mitmproxy running and can see the http flow on the webui on my laptop (running under Widows is fine). However iSmart (Android) bombs out with a message saying proxies are forbidden. Are you Android or IOS? Might IOS make the difference on this?

[HarryFlatter]

Now got iSmart loaded using Wireguard, but now iSmart doesn't trust the CA cert so it won't issue any commants.

I see what you mean by it being a PITA!

Just for ref, all my efforts up to now are completely informed by ChatGPT.

Jsst one thought - which group is the HS PHEV in...

• Fan-speed models (most cars): a Low / Medium / High fan slider plus Cool / Fan Only / Off HVAC modes (and Heat on models with a confirmed heater, e.g. the MG4 Electric). This is the default and covers the standard MG4, MGS5, Cyberster, HS PHEV, and any model not specifically profiled.
• Mode-select models (e.g. MG S9 PHEV, MG4 EV URBAN): on some cars the SAIC API's "fan speed" value is not a fan speed at all — it is a fixed climate mode selector, and the car chooses its own fan speed. On these models a Low/Med/High slider is misleading, so instead the integration exposes HVAC modes and presets that map to the car's actual modes (see below). The correct scheme is selected automatically based on your vehicle. Available modes and presets vary by model — a car is only offered Heat or a Defrost preset if it actually supports them (the MG4 EV URBAN, for example, has no heat mode).
• Simple-AC models (e.g. MG3 Hybrid): a few cars only act on the basic AC command and ignore everything else, so they get a stripped-back Cool / Heat / Off climate entity (Cool = coldest, Heat = warmest) with no fan slider (see below).

If it's the first one, might it be worth trying 'Mode Select'? I'm assuming you are handling different models according to these groups, or am I misunderstanding how this works?

Here is the log from Option A....
AC Log 2.txt

[townsmcp]

Yes, you've hit exactly the wall that makes this such a pain. On Android, iSmart both detects the proxy (the "proxies are forbidden" message — WireGuard got you past that) and then pins its certificate, so it won't trust your mitmproxy CA and refuses to issue commands. That second one is the hard part: on a stock, unrooted Android you usually can't defeat pinning without Frida/objection or repackaging the APK, which is a deep rabbit hole. I'm on iOS, which sidesteps most of it — so if you happen to have an iPhone/iPad to hand, that's by far the easier route. Otherwise, don't burn too much time fighting the capture. I learnt the hard way that Android sucks - I used the BuyMeACoffe money from people to buy a Pixel 3 but could only get it partly working with a Wireguard connection.

Good news: your log actually answers a fair bit without needing the capture. The fan-speed start worked cleanly — the car accepted "AC on, fan speed 3" and reported climate running (remoteClimateStatus went 0 → 3). The only failure was when you turned it off: a 500 from the API on the stop command, and the client didn't retry. The SAIC API 500s on /vehicle/control fairly often, so my first question is: does the stop fail every time, or was that a one-off? If you start and stop the AC a few times, does it usually go through?

On the grouping question — good instinct, but I'd hold off on Mode Select for the HS PHEV. Mode Select is for cars where the "fan speed" value is really a hidden mode selector, and your log shows the opposite: the fan-speed command worked and the car came on. Switching to Mode Select would remove the fan slider for all HS PHEV owners, and it wouldn't fix a stop error anyway. You can actually test the grouping without any capture: set the fan to Low, then to High, and see whether the car's fan genuinely changes, or whether nothing much changes and only the overall mode does. If Low/Med/High make a real difference, fan-speed (Option A) is correct. If they don't, that's the signal it might be a mode-select car and I'll take another look.

So if you can: (1) tell me whether the stop-500 reproduces, and (2) try the Low-vs-High fan test — that'll tell us far more than fighting the proxy will. Really appreciate the help profiling this one.

[HarryFlatter]

Hi James,
I think I'm giving up on mitmproxy for now. As you have suggested the next task might be to re-package the iSnart APK, but this is already way beyond my pay-grade (skill level and ability) and I would be totally relying on AI not to lead me down endless rabbit-holes.
If I can get hold of an old iPad, maybe I'll have another go.

Questions Hope you don't mind.

1: What would you suggest as being the oldest version of IOS that might work for mitmproxy?
2: Not sure if I should have one, but I have no separate entity to change fan speed - that only exists for the climate entity.
3: You mention trying Airflow toggle if it's exposed. I don't have it, but are you saying it exists? The closest I have is 'Fan only'

So back to my AC Summary....

Summary so far.

• 'Cool' activation by individual entities: I activate the AC using either the separate AC toggle or by selecting 'Cool' on the AC Mode entity. Temperature set to 18.

• Result: AC starts, but in 'Manual' mode (previously left in 'Auto'). It sets the fan to 6 (out of 11) and 'Lo' for temp, completely ignoring my temp setpoint.

• 'Cool' de-activation by individual entities: BREAKING NEWS! Standing by the car when I try to turn off the AC, the command does actually work, despite the 500 errors. However as there is no positive response from the API, the entities (AC toggle and AC Mode) remain on until I refresh the car data. I have verified this on iSmart, by refreshing on the app which shows the AC as OFF. Refreshing HA, then shows same.

• Fan only' activation by individual entities: I activate the Fan only by selecting 'Fan Only' on the AC Mode entity. Temperature set to 18.

• Result: Fan starts, but in 'Manual' AC mode (previously left in 'Auto'). It sets the fan to Auto (max) and 18 for temp. So running AC (albeit Manual) when it should only be the fan.

• 'Fan only' de-activation by individual entities: BREAKING NEWS! Standing by the car when I try to turn off the Fan only, the command does actually work, despite the 500 errors. However as there is no positive response from the API, the entities (AC toggle and AC Mode) remain on until I refresh the car data. I have verified this on iSmart, by refreshing on the app which shows the AC as OFF. Refreshing HA, then shows same. For ref, when the car was running

Here is the log of the Fan only event. It's a bit longer than I wanted, but for some reason the car has stopped reporting charging info again!
Fan Only Log 1.txt

I don't know if the log helps, but I'm guessing it would be mighty handy to know what iSmart is crafting for an AC session and an Airflow session.

[townsmcp]

Thanks Harry — this is really useful, and your log confirms it. The good news: the commands are physically working. In the log the car's climate status changes correctly (on, then off) even while the API keeps replying "instruction failed, try again later." So the car is doing what you ask — the API just isn't reporting success back, which is why the AC toggle and Mode entities stay "on" until you refresh. That's on my side to improve: I can make the integration re-check the car's state a few seconds after a command even when the API returns one of these errors, so the entities catch up on their own. I'll look at that.

The other thing — Cool ignoring your setpoint and forcing fan 6/"Lo", and Fan Only actually running the AC — tells me the HS PHEV isn't behaving like the standard fan-speed cars, which matches your hunch. The catch is I can't map it correctly without seeing what the iSmart app actually sends for each mode, and that's exactly the capture the cert-pinning is blocking. So if any HS PHEV owner on an iPhone manages a capture, that would crack it.

On your questions:

1. iOS itself isn't really the lever — on any modern iOS you can trust the mitmproxy CA easily; the wall is the app pinning its certificate, which depends on the iSmart app version, not the iOS version. So an old iPad only helps if it lets you run an older, non-pinning app version, and even then it's not guaranteed. If you can lay your hands on an iPad or iPhone it is significantly easier than Android to intercept the connection. As long as the Apple device runs an OS version compatible with the latest iSmart app you will be fine.
2. No separate fan-speed entity is expected on your car — fan speed lives inside the climate entity, not as its own control. You're not missing anything.
3. The Airflow control only exists on certain models; on the HS PHEV the exposed climate controls are the climate entity, the AC toggle, and the AC Mode select (with Fan Only). So "Fan Only" is the nearest equivalent for you.

Really appreciate the thorough testing — it's told me more than the capture would have.

[HarryFlatter]

Working on getting an iPhone.

In the meantime, I'm pressing on with my HA dashboard.

One question, with regard to the max number of API commands that can be send without starting the car with the key, would there be any concept of aggregating commands to circumvent this. So for example, on a cold morning, I want to switch on both seats, the front and rear demist and the AC - is that doable?

[townsmcp]

Hi Harry, Hopefully this gets through, what with GitHub issues at the moment. Unfortunately not. I think I have tried to save as much as possible for the 3 commands by not sending the target temperature but that seems to be it. Unfortunately those entities you mention are discrete standalone controls - from the app you can’t send a ‘batch’ of commands as one button press from what I have discovered (if you know differently do let me know!) - it’s very frustrating the 3 command limit before starting the car with a key (or phone if you car is capable of using a phone as a key). I have tried a lot of tests to see even if the counter/mechanism is in the API but I don’t get anything to hook into sadly. The only thing I can suggestion is raising a complaint with SAIC via the app/social media asking them to up their limit like the way I have. But I think it will fall on deaf ears. It’s very frustrating as other car manufacturers don’t have the 3 strikes and your out policy (well, Mazda and Mercedes certainly don’t)

…

Sent from my iPhone On 17 Aug 2026, at 3:47 pm, HarryFlatter ***@***.***> wrote:  Working on getting an iPhone. In the meantime, I'm pressing on with my HA dashboard. One question, with regard to the max number of API commands that can be send without starting the car with the key, would there be any concept of aggregating commands to circumvent this. So for example, on a cold morning, I want to switch on both seats, the front and rear demist and the AC - is that doable? — Reply to this email directly, view it on GitHub<#262?email_source=notifications&email_token=ADLJAMLDFJOS4VXJILNLDTL5KMLHZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBQGUZTGMJQUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18053310>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLJAMIS3UVCS7RTFJMKRZL5KMLHZAVCNFSNUABIKJSXA33TNF2G64TZHM4DGNJUGI4DOMZVHNCGS43DOVZXG2LPNY5TCMBVGUYDSNZSUF3AE>. You are receiving this because you commented.Message ID: ***@***.***>

[HarryFlatter]

As you say, deaf ears! Especially since the API is not even published and there is no documentation. Why would they help a bunch of reverse engineers.
Does iSmart suffer from the same limitation? If so, how does it manifest itself. If not, can we not reverse engineer the sh!t out of it to find out how?

[HarryFlatter]

Interesting and a typically disappointing tale of short-sighted companies like that.

Just thought I'd mention it.

Ah well, back to the iPhone search.... :-)

[townsmcp]

lol, honestly it was certainly worth putting it out there, but sadly my experience with them was not good.

I do appreciate the suggestion though.

Good luck with the iPhone search - a couple of months ago I gave my iPhone 12 Pro Max away to family memebers as the trade in value was just crazy (I think it was something like £50) - offers do come up every now and then, just a matter of time. And I reckon you could go back a couple of generations from that as well

[townsmcp]

@HarryFlatter I do have an alternative way that we may be able to get these logs. And let me start by saying I completely understand if you are not interestd in this approach.

So, we could get you to disable the integration in your HA, I then log into my phone with your secondary email address and password and perform 3 climate tests while capturing the full logs via mitmproxy. If you only have 1 secondary account linked to iSmart, you could create a whole additional secondary account (you can have 2 secondary accounts in iSmart) and you can then lock it down so only allowing me access at a certain time etc and then delete it after we have captured the logs. The 3 commands I would test to grab logs are:

AC On @ 16°C — the bottom of the numeric range
AC On @ 23°C — the middle
AC On @ 30°C — the top of the numeric range

And a refresh in the app between command sends.

Like I say, I completly understand if you are not interested in this at all

[HarryFlatter]

So you would log in using my secondary account credentials as your primary. You would then see the HS version of the app as I see it?

Or possibly not quite the same as I've just seen the snaps that the other chap sent you and I'm guessing he must be iOS.

Either way, I am quite happy for you to run riot with my car:-). I'll get a 3rd account set up and we can schedule a session.

I'm going to attach 2 snaps of my Android app and you will see there are just 3 possible AC actions that I have available.

On the home screen I have AC Airflow and on the AC page you can set the temp and switch the AC on or off. For ref, if you change the temp, the app immediately fires up the AC without waiting for me to hit the On button.

The results of these actions are:

AC Airflow: Switches off all AC and simply runs the fan at 9 out of a max of 11

Setting AC temp OR switching ON the AC: Sets the AC to full auto and set temp to that selected

From HA,

I can set temp, turn on AC or set AC Mode to 'Cool' and as Rob Neal has observed, all we get is Manual AC, fan 6 and 'Lo' temp

The closest to AC Airflow we have is AC Mode Fan Only and that results in: Manual AC, fan to Auto (max) and 18 for temp (which is what ws set in HA). So running AC (albeit Manual) when it should only be the fan.

[townsmcp]

By the sound of it the other thread is an Android user as well due to “ Regarding the other test, I've never done this but also don't have an iPhone” so I’m not sure why the pictures look so different - my iPhone looks like the other threads pictures rather than yours.

If you want to bail out after you have had more time to think, I won’t be offended.

ultimately I can do more than 3 tests but I don’t want to be a burden to you as it would involve you popping to the car and starting it to clear the 3 command limit

[HarryFlatter]

It's a poxy theme setting!
I'm on the dark theme. Just switched to the same as Rob and I now have all his controls, including the Presets High & Low. Odd that my theme doesn't reveals these.

I've now registered another 'secondary' account. However, I bow to your knowledge, but if you are going to log in with this user, I have a feeling that it's going to require that you bind that address with the car. However, no time like the present...

How shall I get these credentials to you? You have my e-mail address & phone number from that DM that I send you. Pinf me something and I send them back and we can try it as soon as.

[HarryFlatter]

James, can we do this tomorrow. I'm on chef duty now. I can confirm that I can log in. I'll do a lock/unlock test later and msg you tomorrow. Any time good or bad?

[townsmcp]

No worries. Tomorrow works for me. Probably about 9ish in the evening? I’m in the office tomorrow and won’t be back home until fairly late

[HarryFlatter]

Hi James, did msg you on MGEV.

Not sure if I was waiting for you or you were waiting for me last evening. Either way, I dozed off about 9pm 😁

As I mentioned , I have set up a 3rd account and have now tested that the it can control the car.

I'm out today, but back from about 4ish. How about you?

[townsmcp]

Hey. Sorry about that - I think I fell asleep on the sofas about 8:30! Very odd for me as usually up until 11pm.
Perfect for setting up the 3rd account.
No worries about being out until 4. I will go look at MGEV.

Just saw your message there from this morning. Sorry. So was that ‘back about 4ish’ as in 4pm (now)?
I have just left work so on my way home now. I guess about 8:30ish pm I should be around? If not earlier. I will message you over on MGEV PM what I am ready to go if that’s ok?

[HarryFlatter]

👍

[townsmcp]

Ready when you are

[HarryFlatter]

credentials sent

[willyroo]

Hi all - n00b here so go easy please!

I have an Australia spec IM5 Platinum, which is the midrange model with 100kWh NMC battery. I ticked the "Adaptive Air Suspension" box so it would be interesting to see if the sensors could be added over time :)

The "IM IM5" device is showing lots of good stuff, especially tyre pressures, SoC etc. Really useful to have in a dashboard.

One quirk - the battery capacity, showing as 72.50kWh

https://imgur.com/a/dgwqia9

Let me know if there's anything I can add to get the actual capacity in the device.

Cheers Andrew

[townsmcp]

The latest beta will allow you to override the battery capacity.
Your image link isn’t working.
Regarding the adaptive air suspension, does the ismart app show you any detail about it? If not then it is very unlikely to be in the API. I actually can’t think of a reason why it would be in the app to be reported on but I guess you never know

[willyroo]

Thanks James - yep the iSmart app doesn't have anything about the suspension so "nothing to see here" I guess :) The iSmart app always shows my interior temperature as 87c, external as 0c. HA shows 21c/21c... Looking forward to the next version, and thank you for getting this up and running. Next time Im in HA I'll buy you a pint of 6X :) https://imgur.com/IY916u7 Cheers Andrew *Andrew Jago* +61 418 455 404 PO Box 3092 | Yeronga Qld 4104

…

On Mon, 24 Aug 2026 at 15:32, James Townsend ***@***.***> wrote: The latest beta will allow you to override the battery capacity. Your image link isn’t working. Regarding the adaptive air suspension, does the ismart app show you any detail about it? If not then it is very unlikely to be in the API. I actually can’t think of a reason why it would be in the app to be reported on but I guess you never know — Reply to this email directly, view it on GitHub <#262?email_source=notifications&email_token=CDIDQS6CAWXY3L32ITWCWKL5LPHNVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRGMYDMNRTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18130663>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CDIDQS43OSTT7TQ5UUVEBXT5LPHNVAVCNFSNUABIKJSXA33TNF2G64TZHM4DGNJUGI4DOMZVHNCGS43DOVZXG2LPNY5TCMBVGUYDSNZSUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CDIDQS57BOTQXVP3MQYRU235LPHNVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRGMYDMNRTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CDIDQSZW2RSTIW2NCWP43E35LPHNVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRGMYDMNRTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[townsmcp]

For the temperature, is HA reading correct? Or the iSmart app? I am guessing iSmart app (maybe you are see °F in the app?). If so, create a new issue ticket and grab some logs and post them to the issue ticket. I can then have a look into why the interior/exterior temps are incorrect for your car and if needed create a new profile

[HarryFlatter]

Hi James,
Greetings from a very warm and at times damp Dordogne.
It maybe a daft question, but is there anything which can tell me how much charging energy has been used in the latest charging session? I have a zappi which can tell me when I'm home, but when I'm away with 'Granny' using a friends electricity, all I can do is work on a manual SOC change and roughly calculate it from there. I know iSmart and the integration show current charging power, but there doesn't appear to be anything to show cumulative energy.

[townsmcp]

Try the sensor.mg_mgs6_ev_efficiency_since_last_charge as it has an attribute that should give you what you want. You may need to update to latest beta for it to work right though

[townsmcp]

[HarryFlatter]

Thanks James, but unfortunately that new sensor is 'unknown' for me. Is it possible that this may appear at some point, since the car has not moved since last charge.
Out of interest, what's the difference between 'efficiency_since_last_charge' (also unknown since updating to most recent version) and 'efficiency_since_charge_soc'?

[townsmcp]

Yes, after a charge the car needs to move before it starts calculating. Unknown is normal.

It’s a different calculation method between the 2. The one ending Soc is calculated by Soc and the other one uses more of the api delivered values. So far on my car they match but MG4 owners should see the Soc version as being more accurate and less sensor going blank

[HarryFlatter]

Thanks for that. Obviously I will take a look if they become live at some point. Do they both have the same attributes?

[townsmcp]

Going forward, after you have driven the car for the first time after the update and generated the numbers to populate ‘Efficiency since last charge’, the sensor will hold values. It just needs that first drive.

Both sensors should have the same attributes after the initial population of data. The SOC version for me is still unpopulated with any data or attributes as I haven’t charged the car in a few days (lol kids needed picking up late last night so I decided to hold fire until tonight to make full use of IOG)

[HarryFlatter]

Hi James,

Looks like SOC version is absent for PHEV. The other one does give me the attributes as per your screen shot above, but I'm struggling to see how they will give me a last charged energy. 'Energy kWh' is what has been burned since last charge. I want to know how much I put into the battery at the last charge.

At this moment in time after 2 trips on 100% EV (no fuel used) the Power Usage Since Last Charge is defo appox 3 times what it should be. Here are all the relevant values...

Electric Range 53 mi (out of 75) (extra 2 miles due to regen)
Estimated Range After Charging 75 mi
Mileage Since Last Charge 24 mi
Power Usage Since Last Charge 20.20 kWh Approx 3 x too large
State of Charge 72.1%
Total Battery Capacity 24.70 kWh

I did spot this in the logs: lastChargeEndingPower=725 (that's my 3 times too large 100% SOC after a full charge). I don't suppose there is a lastChargeStartingPower=999 or something similar?

[HarryFlatter]

Seen your rapid response James. You don't hang about, do you. I'm not sure I understood it all though😵‍💫
When will your 3 fixes filter through to a 'new' beta?
Re Battery capacity, you may remember when I very first started using the integration, SAIC was reporting my capacity as 72.5. You then profiled it to 24.7 (as per the brochure spec from MG). THen you introduced the capacity override as a configurable option, so I set it to 24.7. I hadn't realised that SAIC had started reporting a real-world figure of 23.2. Anyway, override now deleted and using 23.2 as actual capacity.
With that in mind, my recent figures would mean:
27.9% of 23.2kWh = 6.47kWh
Power Usage Since Last Charge 20.20 kWh / 3 = 6.73kWh
Close enough???

[HarryFlatter]

Thanks for the re-explain of your PR. I think I got most of that now 😜 You were up later than me!
Bit confused on the version. In your PR you say version bumped to 1.2.7-beta4, but this was my current version before your PR. Has that version been 'patched'?

[townsmcp]

Hey @HarryFlatter — all three of these turned out to be real, and two of them are worse than you thought (they affect every car, not just yours). Fixed in #330 (merged) plus a tidy-up in #331, just released as 1.2.7-beta5.

1. Efficiency Since Charge (SOC) — not a PHEV thing

You said it looked "absent for PHEV". It isn't — the entity is created for BEV and PHEV alike, so you do have it. It just never produces a value on any car. I checked mine: charged Friday night, and it's been sat on Unknown the entire time too.

Two bugs stacked on top of each other:

• The sensor was passing the wrong object into its odometer and SOC lookups. SOC got away with it because it has a fallback to the charging data; the odometer didn't.
• That odometer fallback was then looking for mileage in the wrong part of the response. I checked the client library schema to be sure: mileage, mileageOfDay and mileageSinceLastCharge all live in rvsChargeStatus, not where we were looking. So the fallback could never have worked.

No odometer, no distance, no value — every time. The charge-detection behind it was working perfectly all along, which is why it was so unobvious. Both fixed, and it'll populate as soon as you've driven after a charge.

2. Power Usage Since Last Charge — you were right, and right about why

Your instinct that this smelled like the earlier 3× bug was correct, though the mechanism was different this time. The correction does exist and it's the right number — it was just added in a place this particular sensor never reaches. So it was dead code and the sensor carried on showing the raw figure.

Your numbers back it out exactly: 20.20 kWh corrected is ~6.9 kWh, which fits 24 miles against a 53-of-75 mile range readout. Now applied wherever the value is read.

Worth knowing which sensors were affected: Efficiency Since Last Charge and the Last Trip energy figures were already correcting this properly and were always right. Only the standalone Power Usage sensor was wrong — so if those looked inconsistent with each other on your dashboard, that's the explanation.

On lastChargeEndingPower=725 — good spot, and yes, that's the same 3× inflation (725 → 72.5 kWh → ~24.7 kWh real). To answer your question directly: there is no lastChargeStartingPower. I went through the full field list for both charging blocks; nothing of the sort exists. Which brings us to:

3. Last Charge Energy — new sensor, your suggestion

Since there's no starting figure to subtract, the only way to get this is to measure it across the charging session, so that's what it now does. It gives you two independent numbers, both in the attributes:

• From battery percentage — SOC rise × usable capacity. This is the headline value since it works on every car.
• From the car's own energy figures — lastChargeEndingPower minus Power Usage Since Last Charge, which is effectively the energy sitting in the pack. Shown alongside for comparison, and dropped when it doesn't look trustworthy.

Plus start/end/added percentage, duration, average power, and timestamps. There's also a mg_saic_charge_completed event firing at the end of each charge with the same data, which should suit your dashboard.

One caveat for your granny-charging use case: this is energy at the battery, not at the wall. Your Zappi will always read higher, because it's also paying for charger and cable losses — typically 5–10%, more on a slow granny charge in the cold. So it'll get you close for settling up with your friend, but it's a floor, not a meter reading.

Your car's charging dropout got specifically designed around, incidentally. Because your charging endpoint goes quiet the instant a session completes, a naive implementation would log a phantom charge every single time that happened. Session tracking now only acts on polls where the charging data actually came back.

And one more thing your reports prompted

Both of those bugs had the same underlying cause, which is worth saying out loud because it's the more useful lesson: in each case the rule that mattered was buried inside code that no test could reach.

The correction factor sat inside one branch of a sensor's internals — which is exactly how it could be added back in 1.2.6, be the correct number, and still do absolutely nothing. The odometer lookup was boxed in the same way, so its broken fallback went unnoticed for as long as the sensor depending on it stayed blank. Which it did. For everyone.

So I've pulled both rules out into the integration's pure-logic module where they have one home and can be tested directly, with regression tests pinned to the exact shape of each bug — including your 20.20 kWh, which is now a test case. No behaviour change from that part; it's just insurance that neither can quietly break again.

On the capacity — you got there before I could ask

I was going to ask you to check whether you had an override set, because 24.70 didn't match the profile. You've answered it: override deleted, now on 23.2. That's the right call and it makes your Last Charge Energy figures correct from the start.

One correction though, because it matters for trusting the number: SAIC hasn't started reporting 23.2. The car still reports the same inflated 725 it always has. The 23.2 is a figure we hold in the vehicle profile for the AS33P — the real usable capacity, as opposed to the 24.7 nominal pack size from the brochure. So nothing changed at SAIC's end; you've just switched from the brochure number to the usable one, which is the more honest basis for energy maths (you can't actually use all 24.7).

And your arithmetic checks out

27.9% of 23.2 kWh = 6.47 kWh
20.20 kWh / 3     = 6.73 kWh

Close enough — yes, and usefully so. Those are two genuinely independent routes to the same number (battery percentage against known capacity, versus the car's own energy counter with the correction applied) landing within about 4% of each other. That's the first real-world confirmation I've had that the correction factor is right, so thank you — it's exactly the cross-check I couldn't do on my own car, since mine doesn't have the inflation.

It's also mildly interesting that the SOC route reads slightly lower. With one data point I'm not going to start tuning the factor on the strength of it, but if you fancy jotting down both figures over your next few charges, that would tell us whether the 4% is a consistent bias worth correcting or just noise. No obligation.

On the version — sorry, that one's my fault

Good catch, and the confusion is entirely mine. Here's what happened: when I released beta4 on the 27th I tagged and published the release, but didn't bump the version inside the integration's manifest, which was still reading beta3. So the release you installed says beta4 (that's what HACS shows you) while the code inside thinks it's beta3.

I then wrote the PR against that manifest and bumped what I thought was beta3 → beta4 — straight into a version number that already existed and that you were already running. So no, beta4 hasn't been patched; my PR was about to create a second, different beta4, which would have been thoroughly confusing for everyone.

Fixed — these three changes have landed as 1.2.7-beta5.

[HarryFlatter]

Storming job James!

Need to do a charge to check the new sensor.

I can verify that Power Usage Since Last Charge is now showing correct figure. Also Efficiency Last Charge and Efficiency Last Charge SOC both check out to my calcs exactly.

One question: Since Last Trip Distance, Last Trip Efficiency and Last Trip Fuel Economy all share the same list of attributes but with different headline values (but also contained in the attributes), might it make sense to simply have one sensor called Last Trip with say, the distance travelled as the headline? for one thing it would avoid an 'unknown' on fuel economy when last trip was all electric.

[townsmcp]

By having the separate sensors it makes it history trackable for the sensor headline value which we would loose if we had one sensor with individual attributes

[HarryFlatter]

Added Electric Mileage

Another one for you James. 'Added Electric Mileage' has never populated on my car. Should it, or is it reserved for BEVs. I guess I could calculate it with an automation by subtracting the range at 'start of charge' from range at 'charge complete'. Just seems odd that mine remains at '0', as opposed to unknown.

[townsmcp]

@HarryFlatter — good catch, and the answer turned out to be more interesting than "it's for BEVs".

What that sensor is

Added Electric Range (I think that's the one you mean — there's no separate "Added Electric Mileage", and no PHEV variant; BEV and PHEV get the same single entity) exposes the API's chrgngAddedElecRng. That field lives in the live charging block, right next to "charging time remaining" and charging speed. So it's a counter that runs during a session and resets when the session ends — never a record of what your last charge delivered.

Which means your instinct was right that it ought to retain something, but the field was never designed to. To your point about it showing 0 rather than unknown: that's deliberate, because for a live counter zero is a real answer, not missing data. Same treatment as charging duration and time remaining.

Except it doesn't work anyway

Here's the part I didn't expect. I checked my own car's history across a full charge — five hours on AC, 37% to 80% — and Added Electric Range sat at 0.0 for the entire thing. Not just when idle. During the charge.

So it's not a PHEV limitation and it's not you. The car doesn't populate that field at all, and the honest-looking 0 has been hiding it. That's now four for four on this thread: every issue you've raised has turned out to be broken for everybody rather than specific to your HS.

What you asked for instead

You said you could calculate it with an automation by subtracting range at start of charge from range at charge complete. That's exactly right — and it's precisely the pair of readings the new charge-session tracking already captures for Last Charge Energy. So rather than have you build it, I've done it there.

Coming in the next beta, on Last Charge Energy:

• range_added_km — range the charge added
• range_start_km / range_end_km — the readings at each boundary

It uses the electric range figure that demonstrably does work (it's what drives your 53-of-75 readout) rather than the field that doesn't. It's on the mg_saic_charge_completed event too, if you'd rather trigger off that than poll the attribute.

One deliberate quirk: if range falls across a charge, the delta is dropped rather than reported, but both endpoint readings are kept so you can still see what happened. Cold packs sometimes re-estimate downwards mid-charge and I'd rather show you nothing than a negative.

Something you could help with

I've left the Added Electric Range sensor in place rather than removing it, on the chance it works on models neither of us has. If anyone reading this sees it show a non-zero value during a charge, I'd like to know — that would tell me whether it's worth keeping or whether it should go.

There's also a possible lead I haven't chased: the API carries a companion chrgngAddedElecRngV field next to it, and in this protocol a V suffix usually flags whether the main value is valid. We've never read it. It's plausible the car is signalling "no data here" and we've been displaying the zero regardless. If that turns out to be it, the fix would be to show unknown instead of 0 — which would at least have made this visible years ago instead of looking like a working sensor reporting nothing.

[HarryFlatter]

Good to see my skills at breaking things or finding already broken things remain undulled.😜😁 In a former life, I ran a team of developers on a financial information distribution system for dealers & brokers. I was the bane of their lives, getting involved in system testing and finding stuff they had signed off as 100% to spec.

Thanks again for such a comprehensive investigation and resolution. My life in the city would have been so much easier if some of my people took a leaf out of your work ethic manual!

[townsmcp]

lol similar to what I do now then - a tech data BA in FS. lol the last week I have peed off our 3rd party devs as I keep finding bugs in their updates

[townsmcp]

@HarryFlatter — got to the bottom of Added Electric Range, and the answer is that it's a dead end. Here's what it actually is, and what you're getting instead.

What that sensor is

I think that's the one you mean — there's no separate "Added Electric Mileage", and no PHEV variant. BEV and PHEV get the same single entity.

It exposes the API's chrgngAddedElecRng, which lives in the live charging block right next to "charging time remaining" and charging speed. So it's a counter meant to run during a session and reset when it ends — never a record of what your last charge delivered. Your instinct that it ought to retain something is a perfectly reasonable bit of product design; it just isn't what SAIC built.

That also explains the 0 rather than unknown: for a live counter, zero is a real answer, so the integration treats it the same way as charging duration and time remaining.

Except it never reports anything anyway

I checked my own car's history across a full charge — five hours on AC, 37% to 80% — and it sat at 0.0 the entire time. Not just when idle. During the charge.

I then thought I'd found the explanation: the API carries a companion chrgngAddedElecRngV field, and in this protocol a V suffix usually flags whether the main value is valid. Plausible theory that we'd been displaying a zero the car was flagging as meaningless.

Wrong, as it turns out. I grabbed a live debug capture mid-charge with current flowing, and chrgngAddedElecRngV reads 0 — but so does chrgngRmnngTimeV, on a field reporting a perfectly healthy 300 minutes. So 0 there means valid. The car is asserting that zero added range is the truth.

So it isn't a PHEV limitation, it isn't your car, and there's nothing hiding behind a flag. The field simply isn't populated, and an honest-looking 0 has been concealing that. Four for four on this thread — every issue you've raised has turned out to be broken for everybody rather than specific to your HS.

I've left the sensor in place rather than removing it, in case it works on a model neither of us has. If anyone reading this sees it show a non-zero value during a charge, please say so.

What you're getting instead

You said you could work it out with an automation by subtracting range at charge start from range at charge complete. That's exactly right — and it's precisely the pair of readings the new charge-session tracking already captures. So rather than have you build it, it's now built in.

Coming in 1.2.7-beta8, a new Last Charge Range Added sensor. It uses the electric range figure that demonstrably does work — the one behind your 53-of-75 readout — rather than the field that doesn't.

It's a proper sensor rather than just an attribute for a specific reason: Home Assistant converts sensor readings to your unit system but never converts attributes. As a fellow UK user you'd have got kilometres sitting next to everything else in miles. The raw range_added_km, range_start_km and range_end_km values are still there as attributes on Last Charge Energy for templating, and on the mg_saic_charge_completed event — just be aware those are always km.

One deliberate quirk: if range falls across a charge, the delta is dropped rather than reported, though both endpoint readings are kept so you can still see what happened. That's less exotic than it sounds — I caught it happening in my own capture, where preconditioning the cabin while plugged in knocked 13 km off the estimate mid-charge.

And a bonus your log question led to

While confirming all this I noticed a field we don't expose at all: imcuChrgngEstdElecRng. On my car mid-charge it read 410 while current range read 257 — that's the car's own estimate of the range it expects to have when the charge finishes.

That's arguably closer to what most people picture when they hear "added range", and it's live rather than only available after the fact. Not in beta8, but it's going on the list.

[HarryFlatter]

Just doing a granny test. With Estimated Range AFter Charging, when does this get populated. SOC and Current Electric Range is increasing as expected, but ERAC still 0. Or, can it not calculate this until charging complete?

[townsmcp]

Hey @HarryFlatter

No, it shouldn't wait for the charge to finish. It's meant to be a live estimate that updates as you charge: "if I let this run to your target, here's the range you'll have". On the BEV it was verified against, it read 255miles mid-charge while current range showed 159miles, and it moved during the session.

So a flat 0 while your SOC and range are climbing means your car isn't reporting the underlying value at all.

Context on what changed in 1.2.7. This sensor used to read a field called bmsEstdElecRng, which turned out not to be a range-after-charging figure at all — on a test car at 57% with 177 miles showing and an 80% target, it claimed 473 miles, further than that car goes on a full charge from empty. We repointed it to imcuChrgngEstdElecRng, which on the same car landed within 3% of the expected figure.

That was verified on one BEV, and the release notes flagged that a PHEV confirmation was needed. Your granny test is that confirmation, and it's telling us the field may be BEV-only.

If so, this is the second time your HS has come up empty on this part of the API — chrgngAddedElecRng behaves the same way, reporting a genuine zero rather than missing data. There may be a whole block of fields the PHEV simply doesn't populate.

Two things that would settle it

1. A debug log taken while charging, so we can see imcuChrgngEstdElecRng, imcuVehElecRng and imcuDschrgngEstdElecRng along with their …V companions. If all three are absent or zero, that confirms the block is empty on PHEVs and we handle it properly — showing unknown rather than a misleading 0, and possibly not creating the sensor at all for affected models.
2. You saidAdded Electric Range sensor showed 0 miles for you before 1.2.7? just want to confirm that again, as I cant see what the point of that sensor was previously (maybe the old API used to populate it) — then our change traded one useless value for another on your car, and I'd want to know that rather than assume it's an improvement for everyone.

Meanwhile, something that does work on your car

Last Charge Range Added, new in 1.2.7, gives you the range a charge actually delivered. It's calculated from your Electric Range readings at the start and end of the session — the same figure behind your 53-of-75 display, which we know is populated on your car — rather than from the field that isn't.

It's after-the-fact rather than a live projection, so it won't tell you mid-granny-charge where you'll end up. But for "how much did that overnight charge give me", it should work where this one doesn't. Worth checking once your session completes, and it'd be useful to know either way.

Sorry to hand you another "this was broken all along".

[HarryFlatter]

Hi James, I'm guessing the elephant in the room said "hello" when you said "on a test car at 57% with 177 miles showing and an 80% target".
If you remember Target SOC wouldn't accept a value on the PHEV so the entity doesn't even exist for me. So are we calculating ERAC against a null/0 Target SOC?

As per bloody usual, my car has given up the ghost in terms of charging info about an hour into the charge! Just pondering this issue, is it possible that the PHEV is saying "stop bloody asking me about charging every 5 minutes!" and eventually saying "right, I'm not listening any more!".

I might try an experiment with my next granny charge and increase the charging update to once every 30 or even 60 mins and see if that delays or eliminates the charging silence. Out of interest, does the charging process issue any unsolicited updates, a bit like the door lock status does and is picked up by your once a minute listener? It might be significant that iSmart does not auto-poll the charging data at all.

[HarryFlatter]

Nabbed before it stopped talking to me:

"imcuChrgngEstdElecRng":0
"imcuChrgngEstdElecRngV":0,
"imcuVehElecRng":83
"imcuVehElecRngV":0,
"imcuDschrgngEstdElecRng":0,
"imcuDschrgngEstdElecRngV":0

[townsmcp]

@HarryFlatter — that capture was worth more than you probably realise. It corrected my explanation and caught a bug in the fix I'd already written.

1. Estimated Range After Charging

First, a correction to what I said yesterday. The integration doesn't calculate ERAC — there's no arithmetic on our side, and your missing Target SOC entity isn't an input to anything. The car sends a finished number and we display it. So a null in Home Assistant couldn't have been feeding a bad calculation, because there wasn't one.

Your instinct was still pointing the right way, but your data overtook it. Look at what you nabbed:

imcuChrgngEstdElecRng    0   (V=0)
imcuVehElecRng          83   (V=0)
imcuDschrgngEstdElecRng  0   (V=0)

Current range is there — 83. But the discharging estimate is 0 as well, and no missing target SOC could explain that one, since it's estimating in the other direction entirely. So it isn't "the car can't work out where the charge stops". Your HS doesn't produce range estimates at all, in either direction. Broader than either of our theories, and only visible because you grabbed all six fields rather than the one I asked about.

So we now do the calculation you'd assumed we were already doing. Where the car won't give a figure, the integration projects one from the electric range and battery percentage it does report, scaled to whatever the charge is heading for — target SOC where one exists, a full charge where it doesn't.

• No battery capacity involved. Pure ratio work on a range figure, so capacity profiles and overrides can't affect it.
• A source attribute tells you whether the figure came from the car (reported) or from us (estimated).
• It assumes a charge to full on your car, so it'll read optimistically on exactly the partial granny test you're running. Sanity-checked against a BEV reporting both: 257 km at 51.7% with an 80% target projects to 398 where the car said 410.

Below about 12% battery it shows unknown rather than a number — projecting from a nearly-flat pack amplifies small errors too much to be worth displaying.

And a correction I owe you

Your imcuVehElecRng: 83 exposed something I got wrong yesterday.

I told you Last Charge Range Added would work on your car where ERAC doesn't. It wouldn't have. It reads range from fuelRangeElec, which your model doesn't populate usefully — that's why the Electric Range sensor already reads imcuVehElecRng for your car specifically. Everything derived from range never got that same fallback, so Last Charge Range Added has been quietly blank on your model since it shipped in 1.2.7.

Worse, my new projection would have hit the same wall and returned nothing on the exact car it was written for. You'd have installed the fix and seen the sensor go from a wrong 0 to a blank.

Both now use the fallback. So in 1.2.8-beta1 you should get both sensors working: the live estimate while charging, and the range-added figure once a charge completes. If Last Charge Range Added has been blank for you, that's why, and it should populate after your next completed charge.

2. The charging silence

Does charging send unsolicited updates? Partly. The integration polls your message inbox roughly once a minute, and a message that looks like a charging or plug-in event triggers a refresh. But those come from the messages endpoint, not the charging endpoint — so when charging data goes quiet, the inbox route won't fill the gap. It'll tell us a charge started; it won't keep the figures alive.

You can run your experiment now, no release needed. Options → charging_update_interval, in minutes, default 5. There's a separate dc_charging_update_interval for rapid charging. Set the AC one to 30 or 60.

Your point that iSmart never auto-polls charging supports the theory nicely. If the car or the SAIC backend is rate-limiting, or simply losing patience at a five-minute cadence, that would explain a dropout an hour in — and why this looks so much worse on your car than mine.

The one thing that would make the result diagnostic: note roughly how far into the charge the silence starts, at 5 minutes versus at 30.

• Time-based — it goes quiet at about the same point either way, an hour in regardless.
• Request-count-based — a six-times-longer interval pushes it out roughly six times further.

Those point at completely different fixes, so which one it is matters more than that it happens.

Worth noting this is the same endpoint that goes silent the instant a charge completes on your car, which we already had to design around so it isn't mistaken for the charge ending. A mid-session dropout may be the same behaviour arriving early.

If you are hasnt finished charging yet, it would be great if you can install the update and come back to me when it has finished just so I know if this has worked or not. If it has, I want to get the 1.2.8-beta1 released ASAP so other PHEV users also manage to get a good working set of sensors. If you have finihsed charging then no worries, I can get it out next time you charge and confirm it, fingers crossed, works.

And on the former life — the systems that survive contact with users are the ones that had someone like you on them before release. Please keep breaking things.