Yeah I think that’s a limitation of the MQTT integration. It won’t talk to two brokers at once, hence the need for a bridge.
If you can use the Solar MQTT broker for everything (assuming it supports non-Solar Assistant topics) then that’s probably the easiest way to avoid lots of reconfiguration. You could point HA and the SAIC add-on to that broker (0.160) and let it do everything.
You’d need to confirm it will support this scenario though.
Thanks, yes I see that now.
I run HA on a Proxmox VM (thanks to major help from WP member curto), so I can take a snapshot and rollback as needed. It’s now my normal process before major updates. Backups are automated.
I admit to not understanding the difference between an MQTT broker and an MQTT bridge, only that what I have doesn’t work and I need to try this instead.
While it’s a good suggestion (and I don’t know whether it would or would not work) but I think I’d rather not do this and will attempt to set up the bridge. I may need to come back to it if I fail with the bridge approach.
I have no idea what, if any, breaking changes the Solar Assistant developer might introduce in future, and since they went to the trouble of outlining how to set up an MQTT bridge in HA as a way to resolve this problem it would seem sensible to go down this path.
Also I want my Solar Assistant Raspberry Pi to just focus on doing the job of managing the interface with my off-grid energy system. I’d rather not be reliant on it managing other stuff from a hardware/uptime standpoint. Better those other tasks be on my HA hardware which is more robust and is automatically backed up (there are no auto backups with Solar Assistant). Unfortunately there is no option to run Solar Assistant on different hardware.
If I understood these things better I’d probably work out it was better to have an MQTT bridge/broker running on it’s own VM, but that’s way past my pay grade!
I will give this a go, hopefully today, and will report back.
Thanks to you and others for all the tips, pointers and encouragement.
Looks like the MG server is still down nationwide in any case.
Time for an update.
EDIT: ISSUED RESOLVED - SEE FOLLOWING POST FOR DETAILS
I installed the MQTT bridge as described in the Solar Assistant documentation. That is working with my Solar Assistant. All sensors reading as normal and control going the other direction are working too. So it is a relief that part works.
So what I now need to do is work out how to add the SAIC/MG stuff.
The MQTT custom config file looks like this:
/share/mosquitto/solar_assistant.conf
connection SolarAssistant
#remote_username solar-assistant
#remote_password solar123
address 192.168.0.160
topic # in
topic solar_assistant/# out
The username and password are un-used placeholders in my instance.
I’m now assuming I need to set up a similar config file for the SAIC MQTT feed but not I’m entirely sure about that.
I think I might have it.
I needed to change the MQTT integration settings to point to the MQTT bridge I set up (it was still pointing to the Solar Assistant MQTT IP address):
So I changed that to:
At first it was only giving me the topics sent from Solar Assistant but the system controls were inactive. Those must work, non-negotiable.
Not sure what was up so I stopped and restarted MQTT in Solar Assistant, then the Solar Assistant controls in Home Assistant all came back to life!
And I also have the SAIC stuff:
I profess to not really understanding how or why this works but it seems to be working.
Naturally what this means is now working out what I can do with the SAIC data. Assuming that is MG sort out their data connectivity outage. I’m caught up in this mess, there’s no connectivity with the car.
Once again thanks for all the help and pointers. And for showing me something else which will no doubt result in many hours being wasted used productively.
MG’s data outage seems to be fixed. Integration is now populating with data:
I have our new MG4 integrated and that works fine, except it does not update the info when charging. I manage the EVSE with HA and need to see which vehicle is connected for several functions. But the MG4 sits there charging happily for hours without updating the charger connection status or the state of charge.
Is this normal behavior? Can I force an update (f.i. when the EVSE state changed to connected)?
Are you using scheduled charging, or are these ad-hoc charging sessions?
There’s a few things potentially at play:
Thank you for your reaction.
This is ad-hoc charging, no schedule (not in the car, not in the charger, not in HA). Actually all HA automation was disabled.
Below is an example of what is happening:
Vehicle connected at 8:54 (reported by the EVSE) and starts charging. Connection to the EVSE never confirmed by the car, SoC updates only when disconnected at 11:15.
Car again connected at 12:28 and starts charging. Connection confirmed at 12:29, but SoC only starts updating at 12:50.
Also plotted the ‘active refresh period’ (30 s). The ‘inactive refresh period’ is set at 86400 s. And I found a ‘charging refresh period’ as well, that however is a sensor not a number (can’t set it) and shows some interesting behavior.
The polling mode (refresh mode?) is set as ‘periodic’.
I would think the issue relates to the ‘charging refresh period’. The updates indeed happen following that period. For the first charge never (period is 0), for the second charge first 20 min. then 6 min.
The car sets that period? Is there a bug that sometimes it is not set (left at 0) when charging starts?
Your experience is very similar to mine when you are charging and it’s not scheduled.
The car doesn’t set the refresh period, it’s entirely the SAIC HA addon that is controlling the polling intervals.
The SAIC github page isn’t brilliant as far as the documentation goes, but from what I could understand when I first set it up (this is based on various pull request comments I saw in github, plus some of the code snippets).
Like you I use 86400 for the inactive polling period.
Scheduled charging
When you use scheduled charging and polling mode is periodic, the add-in will poll the car shortly after the scheduled charging window commences. It then calculates a suitable charging refresh period (“MG4 Gateway charging refresh period” sensor in your case) to keep polling with.
The scheduled charging behaviour has been completely predictable for me, and I can see the SOC and refresh period automatically refresh approx 10 mins after scheduled charging commences.
Ad-hoc charging
When you are ad-hoc / non-scheduled charging and polling mode is periodic, your experience will vary depending on a number of variables.
After completing a drive, the add-in continues to poll the car at a reduced interval for a “grace” period - this is the refresh/period/afterShutdown and refresh/period/inActiveGrace topics.
If you commence charging within this grace period, the add-in will calculate the charging refresh period and you’ll get stats.
This part has also reliable for me.
If you commence charging after the grace period ends (let’s say you plug the charger in sometime later) or your EVSE prevents charging for some reason (the EVSE has it’s own schedule, there’s insufficient solar or whatever) then you’re now at the mercy of the inactive polling interval, or some external factor to trigger polling.
Danger, Will Robinson! This is the bit where people might be tempted to dial their inactive polling period down to some small number, or change their grace period to some very large number.
Be very careful with this. Polling the car when it is shut down means it has to keep waking up various control modules. You run a high risk of draining the 12v (LV) battery in the car if you poll frequently when the car is shut down and not actively charging.
Ok, so that’s a very long response, but hopefully it helps explain the various behaviour modes of the add-in. Again, this is based on what I learned from PRs, issues and the code when trying to tune the installation for my use case.
If, like myself you’re in AU/NZ and using the “legacy” gateway then I suspect we don’t have some of the fixes rolled into the new European gateway.
So, what should @VdR do? I have to make some assumptions here based on your screenshot.
If your charging commences only a little bit outside of the grace period, then you could extend the grace period moderately, noting the warning above.
If your EVSE is “smart” and HA knows when it’s actively charging, then you could create an automation that changes the polling mode to “force” a few minutes after charging commences. The add-in will change from “force” back to “periodic” automatically, so this is relatively safe. Just be mindful of unexpected failure modes - eg your EVSE repeatedly changing states or some other scenario that results in constant “force” attempts. You can bake some safety measures into your automation easy enough.
You could also change the mode to “force” manually. This is actually what I do. Ad-hoc charging outside of the grace period is so infrequent for me that I just have a button in HA that I press.
Tagging @wattmatters too as I recall from the MG & Whirlpool forums that they have a large solar deployment and EVSE where this scenario could be relevant.
There’s some info contained in the following repo discussions if you want to dig further into the topics:
Hi, I recently started messing around with Home Assistant and just stumbled across this forum post. I’m an MG4 owner in Australia and I’m interested in trying to get this to work.
From skimming through the post, it sounds like other people have got this to work OK eventually.
Just wondering whether anyone has any tips based on their experience, or can point me in the right direction to get this working?
As I understand it, I’d need to install an MQTT broker (presumably Mosquitto) and then install the ‘legacy version’ of this integration (hopefully this will make sense to me once I drill down into the detail).
Would using this integration help to get around the limitation of only one person being able to log into the app at a time? This is an annoying limitation for me as I share the car with my wife.
When you connect the integration, does this log you out of the app, or can you still have one person logged into the app as well as having this integration connected?
What are people using this for? It is possible to use this to control charging the car? I’m eventually planning on installing an EVSE (probably a ZJ Beny) and using OCPP to charge using my excess solar (I’ve already successfully hooked up my Solar Analytics monitoring into HA). In the meantime I’m just using the granny charger, but it would still be useful if I can use home assistant to stop/start charging depending on my excess solar.
Does the home assistant integration also provide details of the vehicle location?
Thanks,
Mark
This thread has most of what you’ll need, but at a high level:
Install an MQTT broker (Mosquitto is good) if you don’t already have one
Install the Legacy version of the SAIC integration
Configure the integration (I have examples in the screenshots on my post above MG Motor Mg5 Electric Car Integration - #112 by PeatyPete )
Yes, but it will also log you out of the app on your phone and make you dependent on your HA deployment.
You could try and start/stop the car charging, however this is a very crude way to control it. It’s definitely no replacement for an OCPP capable device.
The beauty of a smart charger is it can signal the car with charging rates to vary the charging rate in response to solar, etc. As you note the ZJ Beny is a good device for this purpose.
If you frequently stop/start charging the car manually you’re going to be opening/closing the contactors. I’m not sure what sort of life they’re expected to live up to.
I’m using this integration to get stats on consumption, charging rates and to trigger automations based on the physical location of the car (this is a yes to your location question).
My wife and I also use it to remotely start the aircon (which avoids the whole problem of logging each other out of the app all the time).
Thank you for the elaborate explanation.
That is exactly what I saw. For the first charge the vehicle was connected in the morning after a night not used, so outside the grace period. For the second charge it was connected immediately after running an errant, so inside of the grace period.
I’m not sure why the gateway dynamically adjusts the polling while charging, a fixed period would be just fine. Also don’t understand why it starts a with long period and then brings that down, rather than the other way around.
With my HA charge automation (scheduled charge, excess solar, overvoltage protection, undervoltage protection and state of charge limit), it will happen that a charge starts outside of the grace period. Extending the grace period as you say is not a solution.
For charging at home I can force an update from the MG when a charge starts (based on the EVSE state) and then wait to see if it is the MG that is connected (had to do a similar thing for the MG’s predecessor, a fiat 500e). I hope it will then keep updating (with a useful period) until the end of the charge (to be tested).
This issue goes into the rationale and approach in lots of detail if you’re curious: Feature Request: dynamic polling during charging · Issue #52 · SAIC-iSmart-API/saic-python-mqtt-gateway · GitHub
Thanks a mill for this post, it anticipated some questions I had and goes quite a ways to explaining some stuff I wasn’t sure about. i.e. those polling settings. I just left the default settings:
Then I saw this was documented and it makes more sense to me now:
This is definitely my case, so thanks for the shout out. Charging is controlled, for the time being, by ChargeHQ and so depends on either available excess solar PV on weekdays or on weekends waiting for the free tariff period (12-2PM).
On Saturday I had a morning drive and an afternoon drive, with a charge session in between which did not commence until noon, some hours after completing the morning drive. Hence the system did not record data for the charge session:
It did have a lone polling point at 11:05. Not sure why that is. Maybe I selected the force poll option while fiddling about with the system.
So if I have this right, in order to capture data during a charge session, I could set up an automation which detects when a car charge session commences (easy enough as that circuit has power monitoring), and set the system to perform a force poll.
Is that right?
Not sure what else the automation may need to do, e.g. change the poll mode back to periodic?
Your use case sounds very similar to mine. I started with it only last week and many of the posts between this one:
and now were about me getting help with making it work, so there might be some pointers in there about my mistakes and wins. I had a few challenges sorting out my MQTT bridge which may or may not be relevant in your case.
This is what I have. Mine uses Fronius Solarweb data (I have Fronius smart meter), but same principle as Solar Analytics.
Bringing control of OCPP into Home Assistant is my next big challenge. Not quite got the courage for that just yet, so for now it’s being managed with ChargeHQ.
Yes, correct. You could have an automation which switches the mode to ‘force’ when charging commences.
You don’t need to change it back to the previous state (off or periodic), it will automatically revert to the previous state. You can put this to the test easy enough - switch the mode yourself in HA and you’ll see it switch back in your HA sensor and in the MQTT topic with MQTT explorer.
In your case and @VdR, I just realised I should have given an example when I talk about failsafes:
Your automation could be a simple as these few steps, and still be safe:
trigger: EVSE/power monitor indicates charging started
actions:
- delay for 60s to let things stabilise
- change polling mode to force
- delay for 120s
mode: single
By placing a 120s delay as the last action in this example, and setting mode to single, your automation won’t fire in rapid succession if your trigger is repeatedly firing in quick succession for some unanticipated reason.
There should be no need to trigger the automation again when your EVSE/power metering equipment indicates charging ended, as by now the SAIC add-in should be aware charging is taking place and is automatically polling.
Thanks. I removed the action to put it back to periodic. This is my YAML:
alias: "EV - SAIC Start polling when charge session starts "
description: ""
trigger:
- platform: numeric_state
entity_id:
- sensor.input_10_garage_ev
for:
hours: 0
minutes: 1
seconds: 0
above: 500 # wait for EV charging power to be above 500 W for 1 minute
condition: []
action:
- service: select.select_option
metadata: {}
data:
option: force
target:
entity_id: select.lsjwh4099pn196816_gateway_refresh_mode
mode: single
My charging will never have rapid start/stops, there is an auto delay of ~ 15 minutes before it can fire up again after it stops.
I think it’s working. This is this morning after we got back from taking the dog to the beach:
It pretty much started charging straight away, so that would have been inside the grace period. But later it stopped (lack of excess solar PV) and then started again about 20 minutes later. The SOC data seems to be updating.
Did this today and it worked perfectly…
I see a LOT of entities and I suspect several won’t apply to my MG4 like sunroof but I also see a window entity that I thought would open/close each window but it does not seem to do anything so far
Is there a list of entities that we should disable as not applicable to the MG4?
Did you find out? I’m also on 87C haha
Many entities will be providing status data rather than provide controllability.
Thanks man. Do you know which ones I should just disable. Like I said there are 4 switches for the windows and out of the 4 1 is “on” I thought it was indicating an open window but turns out it does not and the other 3 neither haha. Would be pretty amazing though if we could control the windows
MG4 Trophy/Essence here
