Ok so a few things I’ve noticed about the Leaf integration, maybe someone can comment or maybe one of the integration devs can cast an eye over these…
- As I alluded to earlier, PYCARWINGS2_SLEEP which controls how long to wait after sending a request to poll again to see if the thing asked for has been retrieved from the car is set to 30 seconds and there are also three retries set.
Before using Home Assistant I’ve used pycarwings2 directly a reasonable amount in my own python scripting and one thing I learnt is that the minimum time that it takes the car to respond when everything is going perfectly (good connection to the car, Nissan servers behaving etc) is pretty much bang on 30 seconds.
So if the initial delay before checking data has returned is 30 seconds it’s on a knife edge whether the data will be ready or not, and in the vast majority of cases the data will not be ready after a 30 second wait which will result in another 30 second wait before a 2nd attempt. So in the majority of cases it will actually end up polling for the data twice and taking 60 seconds to retrieve it.
Using pycarwings2 directly in the past I found empirically that 40 seconds was the ideal initial wait period - long enough that the vast majority of the time the data will be retrieved on the first try without having to do a retry, but not so long that you’re waiting unnecessarily long. In fact if only one retry is needed it only takes 40 seconds to get the data instead of 2 x 30 waits for a total of 60 seconds, so it is actually faster most of the time.
When the servers are heavily loaded (depending on time of day) I’ve found it can occasionally take up to about 1 minute 10 seconds for valid data to be available, with 3 retries and 30 second delays this will use up all three retries and take 1 minute 30 seconds to get the data, with 40 second delays it would use only two of the three retries and retrieve the data in 1 minute 20 seconds and still have one retry up its sleeve, so also a bit faster in that scenario.
Could I humbly suggest that the default sleep value be increased from 30 seconds to 40 seconds ? 
(or if someone can suggest how I can adjust that value on my local installation in a way that won’t get overwritten by future updates that would be great)
- Switching climate control on/off does work but returns an error. For example if I use the toggle switch through the UI (switch.leaf1sbyr_climate_control in my case) I see a message about 3 seconds later saying “Failed to call service switch/turn_on”, or “Failed to call service switch/turn_off” respectively, regardless of the fact that it does in fact turn the climate control on and off. This error always occurs after about 3-4 seconds, which is far too soon for it to know whether the API call was successful or not let alone get any feedback from the car.
When using a toggle in the UI it’s not a major problem but I realised when trying to call this from a script using call service switch.turn_on that the error also causes the calling script (or automation) to fail, hence further steps in the script are not executed even though the climate control did actually start in the car.
Yes I know there are ways around this by making the call run asynchronously but this seems like a kludge. Should the success/fail status of the change of switch status be reporting whether the climate request was successfully enqueued at the Nissan servers (but not necessarily actioned) or is it actually intended to poll the car for data and confirm whether climate control did actually start ? Either way it doesn’t do either of these at the moment. Possibly related to this error it also doesn’t poll the car for updated status after sending a command to start or stop climate control.
Strangely while there is a pop up error to say that it failed to call the service there is no error in the log even with debugging for the integration enabled, just “2021-12-15 16:55:00 DEBUG (MainThread) [homeassistant.components.nissan_leaf] Requesting climate turn on for MY_VIN”
- This is really just a question - in the code it looks like after 3 retries with no updated data being retrieved from the car the last known values from the server are used instead. As the comments in the script say this is “better than nothing” as that data may have been sent voluntarily by the car at some point such as turn on or shutdown, however is there any way for me to know whether the data retrieved is cached data from the Nissan servers or freshly polled data from the car ?
I initially assumed that the updated_on attribute would be the datetime that the data was pulled from the car (which is available in the API responses) however now I’m not so sure and it looks like this is just the last time that the Leaf integration queried the Nissan servers successfully, regardless of whether the data from the car is fresh or not. In other words its the time of the server query but not necessarily when that data came from the car. Is this the case ?
If so something that would be very useful would be to have another attribute which is the exact date and time that the data came from the car - and this data is available in the API calls but doesn’t appear to be exposed at the moment by the integration.
One reason this might be needed for example is trying to extrapolate a charge end time based on previously time stamped SoC values during charging - something I talk about wanting to do in the thread I linked.
However if there is no guarantee that the updated_on attribute represents the time the data was retrieved from the car and could sometimes be stale cached data from the Nissan servers, such extrapolation of the charging curve cannot be safely implemented…
)
