[new-binding] Integration of SAIC (MG) iSmart based Vehicles

Hi,

I have created a binding for SAIC iSmart based vehicles (sold under the MG label in europe).

Only supports reading out data currently, but remote locking and climate actions should also be possible to add.

Tested currently against a MG5 2022 model.

Download:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.saicismart/3.4.1-SNAPSHOT/org.openhab.binding.saicismart-3.4.1-SNAPSHOT.jar

PR:

2 Likes

@tisoft Thanks for this binding. I am keen to help test and the the PR accepted as soon as I my ordered car arrives…

I have a new MG5 EV with iSmart. Really interested in this binding and if the write functionality can be added. We use the preheat function regularly and due to the limitation of single sign on we would lose this if we moved to the openHAB binding. If I can help with testing then I will.

I just added first experimental support for preheat.

https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.saicismart/3.4.0-SNAPSHOT/org.openhab.binding.saicismart-3.4.0-SNAPSHOT.jar

(Download doesn’t seem to work with a browser, but wget does it)

I have tested and it seems to be working ok. It would be good to be able to start the front and rear defrost and set the temperature on the AC. I will continue testing over the weekend.

Thanks for testing!

The start A/C channel actually starts front defrost, I’m sending the wrong command (5 instead of 2) :smiley:

But I will add proper support for Front/Back defrost and A/C with temperature control. Need to fiddle out the correct parameters first.

Excellent. I have also seen that you have included a force refresh toggle. How often does the data refresh automatically? Can this refresh interval be added at the thing level of the binding? Would be also good to get access to find car features eventually - flash lights etc. Then I think the MG app is redundant as all functionality is here! Excellent work @tisoft !

There was an interesting point raised by a user’s usecase of the renualt binding. They requested an “update now” function here:

I have implemented a polling interval for the renault binding as a configuration parameter and just added an update now switch for forcing a “poll now”. This will hopefully allow rules to update the data when needed. The reanault servers do not like lots of requests and lock you out for a cool down period if you overload the API…

So I think a long polling interval (renault binding defaults to 10 mins) and update now or force update function is good combination.

1 Like

There is a channel “Last Car Activity”. As long as the current time is no later than 15 Minutes after the time in that channel, the binding does updates basically as fast as it can.

The car is marked as active, if either the engine runs, the car is charging or remote climate is activated. This are basically the states of the car when the H/V battery is on.

This works as long as the car is active, but as soon as it not active anymore I don’t do any polling anymore. You can enable start notifications in the iSmart App, that send a message over the API every time the engine is started. I’m polling those and set the car to active to start car polling again.

The “Force Refresh” button sets the active date to now - 14 Minutes, so that the fast polling is enabled for a minute. This can be used to wake up polling, if for example a charger enables charging in the middle of the night, or you want to see the interior temperature in the morning to see if you need to defrost.

There seems to be no API limit on how fast or how often you can query the car data, but if the H/V battery is off, you can drain your 12V battery pretty fast.

I suppose it is possible to query the car once every X minutes in “inactive” mode, to get the car status for a parked car. But after getting my first 12V battery warning in the morning, I haven’t tried that again. :smiley:

Regarding location and light flashing: I plan to support all features, the app supports, or if possible even more. The European App seems to be a copy paste of the Thai-App, with some features disabled, but the code is still there. Maybe some functions are only disabled in the App, but actually working in the API. We will see.

1 Like

Thanks for the pointers. Good idea to request the forced update when specific associated rules trigger.

1 Like

Thanks for the detailed explanation @tisoft. The reason I was asking about the update interval was that I was thinking about passing the SoC to the charger. This of course is only useful when the vehicle is parked. Good news on the added functionality. Look forward to it and will I test it when ready.

@tisoft That sounds like a good strategy.

I do not know how the Renault car <-> server communication works I just translated the python version of the reversed engineered mobile app. The pooling and update now seams to work OK, but the car does not update the server every polling interval. I also added channels for the timestamp of the location and battery status. This was requested by users to help indicate how up to date the information is.

It sounds like the SAIC architecture is different. I would love to help with the testing but I am waiting (since April) for my MG5 to be delivered…

Thanks for your development and testing efforts chaps.

I think there appears to be excessive logging from this binding. Can it be reduced? Log files are filling up and causing the file system to enter write protect and hence prevents Openhab from running.

Yes I am logging very extensive. Will reduce it in the next version.

Hi Markus

Hope you had a good Christmas and new year!

I updated the binding to 3.4.1. One observation I noticed was that the polling doesn’t start by itself when the car is active. I enabled the engine start notifications but that does not seem to be waking up the polling.

I have enabled the data link with ABRP but the link stays disconnected until I force the data refresh in openhab.

BR

Tim