Someone on the MG forums suggested changing the picture to monochrome with a picture editor, which I had a little trouble doing to get a dark enough grey from the original orange but they posted one they created, so I flipped that to portrait and have this so far:
I think portrait mode gives a bit more room to place info icons on the phone screen. I might add a couple of extra things, e.g. the range estimate, odometer.
Iâm trying to run the mqtt gateway via docker. My MQTT container is in the same stack.
Everything can connect to the mqtt container such as zigbee2mqtt and other docker containers but I canât get this gateway to connect even if I run under host mode.
Iâm mqtt is anonymous. Logs just suggest connection refused.
The car (MG4) refuses to charge after the EVSE (Wallbox Pulsar Plus) has been on âPauseâ for a while.
I run an automation on the EVSE to start charging when the Solar inverter (SMA) voltage rises too high. This to prevent the solar system from shutting down. With my Polestar connected this works great, during a two week vacation it prevented dozens of solar system shutdowns.
However with the MG4 it does not (always) work. When the EVSE has been on âPauseâ for a wile, then when the automation kicks in and wants to car to charge, the car does not accept a charge, the EVSE status goes into âWaiting for car demandâ.
What is causing this behavior, what could a work around be?
charging from 12:10 to 12:18 (based on solar inverter voltage)
paused from 12:18 to 16:03, at 16:03 charge initiated, but not starting
waiting for demand from 16:03 on, charging not accepted by the car
PS
This behavior also makes that the scheduled charge automation does not always work.
The only way to start charging again that I could find is to physically disconnect the car and reconnect it again (hard to do from 1000 miles away). Also forcing a refresh does not re-enable charging.
I would agree. Not the MG integration, not the EVSE integration, not the HA automation. It seems to be the reaction of the car to the EVSE switching on and off (more precisely in and out of âpausedâ).
I canât figure out what causes this. Sometimes it works fine a whole day, sometimes it fails after the the first switch. Just wondering if anybody else has seen this work or fail and if there is a fix.
There is a power sensor and a sensor for plugged-in.
You should be able to feed the power sensor to a utility meter when ever the plugged-in sensor is âonâ
ODB plug is not required
Yes.
There are settings for Target SOC, current adjustment for 6/8/16 and Max amps, a toggle to start and stop charging, start and stop times, and a selection for charge till target SOC or till stop time.
I find it difficult to separate out the yaml from all my other dashboard code. Iâm no coder so unfamiliar with whatever useful editing tools there are that might help with this.
This is the dashboard intended for our phones, with the overhead car image. It is placed inside of a 1 card panel (not masonry or side panel view).
Hopefully enough in there to help with the larger dashboard I have for the computer screen, as extracting that from everything else I have on my dashboard is too much.
I have set this up but am having an issue. I have checked the logs and its telling me my accounts been locked and to wait a day or change the password. I have changed the password using the app, but still no joy. The app works fine with new password.
Preformatted text 2024-09-30 13:54:08,659 [ ERROR ] MqttGateway crashed due to an Exception during startup - main
Traceback (most recent call last):
File â/usr/src/app/./mqtt_gateway.pyâ, line 441, in run
login_response_message = await self.saic_api.login()
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File â/usr/local/lib/python3.12/site-packages/saic_ismart_client_ng/api/base.pyâ, line 72, in login
result = await self.deserialize(req, response, LoginResp)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File â/usr/local/lib/python3.12/site-packages/saic_ismart_client_ng/api/base.pyâ, line 185, in deserialize
raise se
File â/usr/local/lib/python3.12/site-packages/saic_ismart_client_ng/api/base.pyâ, line 170, in deserialize
raise SaicApiException(error_message, return_code=return_code)
saic_ismart_client_ng.exceptions.SaicApiException: return code: 15033, message: Sorry, the account has been locked, please try again tomorrow or you may reset password by clicking âforgot passwordâif you forget it.
return code: 15033, message: Sorry, the account has been locked, please try again tomorrow or you may reset password by clicking âforgot passwordâif you forget it.
2024-09-30 13:54:08,704 [ ERROR ] Task was destroyed but it is pending!
task: <Task pending name=âTask-1â coro=<Client._resend_qos_messages() running at /usr/local/lib/python3.12/site-packages/gmqtt/client.py:176>> - asyncio
sys:1: RuntimeWarning: coroutine âClient._resend_qos_messagesâ was never awaited Preformatted text
Hi @PeatyPete and @wattmatters.
You may have already had some similar issues and resolved them but felt others reading this thread may benefit from my troubles. As mentioned my SOC was only updating at the rate of âGateway charging refresh periodâ which is between 1000 and 1500 seconds while charging (between 17 - 25mins).
I have setup some automations that track the excess power being generated and changes the âcurrent limitâ in the MG integration so that I am not drawing from the grid to charge the MG. So the 17 - 25 minute updates were a little bit too long to accurately adjust the current based energy being fed into the grid.
My solution was to create a template sensor that tracks how long it has been since HA received a charge update from the MG, then use an automation to force an update if the car is charging and the time since last update is greater than 300 seconds (5 mins)
#Automation
- id: '17148028106762'
alias: MG current force update when inactive
description: check for update when inactive
mode: single
trigger:
- platform: numeric_state
entity_id:
- sensor.mg4_seconds_since_update
above: 300
condition:
- condition: numeric_state
entity_id: sensor.mg4_energy_flow_from_grid
above: 20
- condition: state
entity_id: binary_sensor.lsjwh4094pn199624_battery_charging
state: 'on'
action:
- action: select.select_option
metadata: {}
data:
option: force
target:
entity_id: select.lsjwh4094pn199624_gateway_refresh_mode
#Sensor
template:
- sensor:
- name: "mg4_seconds_since_update"
unit_of_measurement: "Seconds"
state: >
{% set n = now() %}
{% set t = states('sensor.lsjwh4094pn199624_last_charge_state') | as_datetime | as_local %}
{{ (n-t).seconds }}
I am wary of the 12V battery with the drain issue when polling more frequently and when you stand next to the car you hear some of the systems turn on and the driverâs screen flashes on for a few seconds when the update is sent. Hopefully, the fact that the automation will only run when it is plugged in and charging will mean it will be ok. Do you know if the 12V battery charges during EV charging?
Interesting idea!
I wouldnât be concerned about the LV battery - according to the manual the car charges it automatically as needed (refer the âIntelligent Chargingâ section).
My observation is âIntelligent Chargingâ always takes place when the car is charging. Eg, hereâs my last charging session. You can see the LV battery jump during the session:
Just check the auxiliary battery voltage during a charge session, that will tell you. It is an entity provided by the integration. e.g. here is my carâs charging power and auxiliary battery voltage during a charge session (note, the charging power data is from my own home circuit monitoring, not this integration):
You can see the auxiliary battery voltage rises to over 14 V while the car is being charged, then once the charging has ceased the auxiliary battery voltage drops back to normal resting voltage (a little less as it is being polled for a short while after a charge session).
Hereâs the last 30 days of auxiliary battery voltage data:
Can see how it is regularly lifted >14 V when the car gets charged or is being driven, then drops down in between. In last couple of weeks we have not driven the car aside from this weekend just gone and so can see how the auxiliary battery voltage has slowly dropped in that two weeks.
Note that on the right side the voltage shows the auxiliary battery being charged again - the car in this instance was not being charged, but the auxiliary battery also gets recharged while driving.
