I've enjoyed the journey but...
I'm unlikely to reach my planned destination.
I don't think the infrastructure is ready
My original idea was to make a simple html monitor page available that I could access from anywhere, without the need for login details and without compromising security.The unofficial api access software seems to work well, but the MG stuff is seriously lacking in performance and diagnostic detail.
However, its been very interesting, I've exercised my tired old brain, and I think I have learnt a lot.
I know now that the ev [big] battery maintains the system [12V] battery, even with a SoC as low as 15%. And I'm sure I'll soon have an opportunity to test this for SoC levels below 15%.
who is in my team
I've been using ChatGPT to search for information, write some python, analyse data and make suggestions about what it may mean.
I'm getting much better in this management role, when it comes to these funny AI 'people' (...because they certainly need managing).
the problem
Requesting data via the api is hit & miss. There are frequent, and sometimes long, periods when a data request receives the response: return code 4
The description along with this error basically says: "The remote control instruction failed..." but this is a catch-all error which may mean different things at different times.
For example, it may occur when the car is parked, or being driven, when SoC is high or low, when charging or doing apparently nothing.
It could mean the car is sleeping, or awake but the backend has timed out, or there is a partial ECU failure, or simply a network glitch.
It could mean the backend is imposing a rate limit. But if so, this must be adaptive, based more on overall network traffic, because it does not seem to matter if I request data every 3 minutes or once per hour ...error 4 it just as likely to be returned.
Note that by way of a double check, iSmart suffers in a similar way, frequently unable to get data or control any of its features (e.g. heated seats & so on). So its not only my data requests that result in this response.
API to car comms
This is my visualisation for App to car comms
My guess is that most/all software in the car, and in the server backend and iSmart is MG design, while IoT (Internet of Things) stuff is a service provided by an IoT supplier, probably Scandinavian.
how does MG compare?
I asked AI to gather comparative info for a few car brands/groups
What makes Tesla out-perform the rest? Two words: vertical integration
They have control over everything from the tyres to the app, and the company is software driven!
Unfortunately, MG seem to be at the bottom of this particular heap.
software updates by brand
Here is info compiled by my AI buddy concerning updates, OTA or otherwise.
High-level categories of update models
Before the table, it helps to know the four update models used in the industry:
Full OTA (vehicle + ECUs + features)
→ Tesla-style, centralized architecturePartial OTA (infotainment + limited ECUs)
→ Most legacy OEMsInfotainment-only OTA
→ Vehicle logic still dealer-onlyDealer-only updates
→ No meaningful OTA
EV software update methods by manufacturer
Tesla
OTA scope: ⭐⭐⭐⭐⭐ (industry leader)
Method
Full OTA via cellular + Wi-Fi
What updates
Vehicle firmware
Powertrain
Battery management
ADAS / Autopilot
Infotainment
Architecture
Centralized vehicle computer
User visibility
Detailed release notes
Clear update state
Backend behaviour
Backend can explicitly wake vehicle
Rich error telemetry
Key point: Tesla designed the car around software first.
Volkswagen Group (VW, Audi, Skoda, Cupra)
OTA scope: ⭐⭐⭐☆
Method
OTA + dealer fallback
What updates
Infotainment OTA
Selected ECUs OTA (slow rollout)
Limitations
Early ID software was unstable
Backend complexity causes failures
Architecture
Distributed ECUs with partial centralization
BMW
OTA scope: ⭐⭐⭐⭐
Method
OTA via cellular
What updates
Infotainment
Driver assistance
Some powertrain logic
Dealer still required
Major ECU reprogramming
Strength
Good diagnostics
Clear update state
Mercedes-Benz
OTA scope: ⭐⭐⭐☆
Method
OTA for MBUX + selected ECUs
What updates
Infotainment
Charging behaviour
ADAS tuning
Limitations
Core vehicle logic often dealer-only
Hyundai / Kia
OTA scope: ⭐⭐⭐☆
Method
OTA for infotainment
USB / dealer for vehicle ECUs
What updates
Infotainment OTA
Battery/charging updates via dealer
Strength
Reliable vehicles
Weakness
Conservative OTA strategy
Ford
OTA scope: ⭐⭐⭐⭐ (recently improved)
Method
OTA via Ford Power-Up
What updates
Infotainment
Powertrain
Charging logic
Notes
Major push toward Tesla-like OTA
Still mixed reliability
Volvo / Polestar
OTA scope: ⭐⭐⭐⭐
Method
OTA via Android Automotive
What updates
Infotainment
Battery management
ADAS
Strength
Clear update logging
Weakness
Occasional OTA regressions
Renault
OTA scope: ⭐⭐⭐☆
Method
OTA for infotainment
Dealer for ECUs
Notes
Conservative, safety-focused approach
Nissan
OTA scope: ⭐⭐☆
Method
Infotainment OTA
Dealer-only ECU updates
Notes
LEAF architecture is legacy
Toyota / Lexus
OTA scope: ⭐⭐☆
Method
Infotainment OTA
Dealer-only vehicle logic
Notes
Extremely conservative software policy
Stellantis (Peugeot, Citroën, Fiat, Opel)
OTA scope: ⭐⭐☆
Method
Infotainment OTA
Dealer ECU updates
Weakness
Fragmented platforms
Poor backend consistency
MG / SAIC
OTA scope: ⭐⭐☆
Method
OTA infotainment updates ???
Dealer-only vehicle firmware
Vehicle ECUs
Largely not OTA
Backend
Cloud-mediated telemetry via IoT provider
Limited diagnostics exposed
Known issues
Generic error codes
Poor state awareness
No backend wake diagnostics
Critical point:
See also:-
No comments:
Post a Comment