Closed raphmur closed 2 months ago
Some initial thoughts:
We could have a variable in the code which knows the last value that was set by the code, and only sends a new value via BLE if the request is different. Add some logic when going from >=5 to <5 amps to send the value twice (or send 5 then the requested value). Would this solve the problem you report?
Of course the code doesn't know if the charging current was changed via other means e.g. the Tesla App or the Fleet API. This was discussed in the Issue reported in my original repo https://github.com/tesla-local-control/tesla_ble_mqtt_docker/issues/4
And / or we could use the value_template field in the MQTT config to read the actual value from HA. Your automation could specify the value or get it from Tesla Integation (though how quickly / accurately this responds via the Fleet API would need to be tested)
I see no issue having a local variable (with expiry maybe) that stores the last command. I suggested to have a separate button, since this logic of storing a last state and juggling between different sensors / data sources is easier in HA.
In fact: putting this logic in the .sh script may:
I don't remember... Is there an error message if trying to set below 5a straight in? I think not...
Suggested a PR & issue in _core https://github.com/tesla-local-control/tesla_ble_mqtt_core/pull/20. Closing this one
It is possible to charge below 5A, for this we need to send a command for 5A charge, then decrease to the next value.
I have an automation that updated current every 3min. So pushing constant updates for 3A (eg.) shows a funny behaviour of oscillating charge request of 5A and 3A. When "staying" below 5A the
First Amp set
should not be required.I wonder if we can do it directly with the history of mqtt messages? Otherwise I suggest (though really not ideal) we can implement a new button "charging-set-amps-below-5a" that will only send one command. Then I can manage the difference in my automation.
@iainbullock what do you think?