Using service to set number.mycar_charge_limit to its current value gives error, blocks automation

[fhteagle]

Checklist

• I have filled out the issue template to the best of my ability.
• This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
• This issue is not a duplicate issue of any previous issues..

Describe the issue

Use call: service number:set on number.mycar_charge_limit to its current value returns an error "already_set". This blocks automations from proceeding.

Temporary workaround is to check the value of the charge limit in the automation before setting it, but this is unnecessary extra work. The integration should allow the existing value to be "set" (no change) and return no error instead.

Reproduction steps

1. Note current number.mycar_charge_limit setting
2. Use automation call service action (or developer call service) number:set on number.mycar_charge_limit with value chosen to be the existing value
3. Note error "already set" is returned, which blocks automations from proceeding
   ...

Debug logs

Nothing relevant in homeassistant.log (even with Teslemetry debug logging on), nor System > Logs

[Bre77]

The problem is, this is a response from Tesla, so I would have to hardcode in an exception to ignore this error, or just not make the API call at all if Home Assistant believes the value is the same, however this then causes other edge cases when you want to try change the value anyway.

It would be better for you to account for this in your automation by not calling the service if the value is the same, or adding continue_on_error: true.

I'll add a note about this in the documentation.

[Bre77]

Im having secound thoughts, I think I will ignore already_set errors.

[Bre77]

@fhteagle I am unable to reproduce this message on my Model 3. The fact your not seeing any logs suggests its failing sooner than I expected. Can you please turn on debug logs, reproduce the issue, then disable debug logs and send that through to me either here, email (admin@teslemetry.com), or Discord.

The debug logs will have Command result and Command error when you run the command, which is what I need.

[fhteagle]

Well I figured out why there was not anything in the debug logs about this previously.

This in my configuration.yaml is not actually turning on full debug level logging for the Teslemetry integration after a Home Assistant restart:

logger:
  default: warning
  logs:
    custom_components.teslemetry: debug

With only that configuration.yaml set, GUI does not show debug logging on, and I'm only getting summary-ish lines like this:

2024-05-12 09:02:39.492 DEBUG (MainThread) [custom_components.teslemetry] Finished fetching Teslemetry Vehicle data in 0.372 seconds (success: True)
2024-05-12 09:02:47.611 DEBUG (MainThread) [custom_components.teslemetry] Command result: {'response': {'result': True, 'reason': ''}}

Until I go into the GUI and select debug logging on , then I get more full output like this:

2024-05-12 09:05:14.121 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/vehicles/***myvin***/vehicle_data
2024-05-12 09:05:14.121 DEBUG (MainThread) [tesla_fleet_api] Parameters: {'endpoints': 'charge_state;climate_state;drive_state;location_data;vehicle_state;vehicle_config'}
2024-05-12 09:05:14.292 DEBUG (MainThread) [tesla_fleet_api] Response Status: 408
2024-05-12 09:05:14.292 DEBUG (MainThread) [tesla_fleet_api] The vehicle is not 'online'.
2024-05-12 09:05:14.292 DEBUG (MainThread) [custom_components.teslemetry] Finished fetching Teslemetry Vehicle data in 0.172 seconds (success: True)
2024-05-12 09:05:29.476 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/vehicles/***/wake_up
2024-05-12 09:05:29.629 DEBUG (MainThread) [tesla_fleet_api] Response Status: 200
2024-05-12 09:05:29.629 DEBUG (MainThread) [tesla_fleet_api] Response JSON: {'response': {'id': ***an_id***, 'user_id': ***a_user_id***, 'vehicle_id': ***a_vehicle_id***, 'vin': '***myvin***', 'color': None, 'access_type': 'OWNER', 'granular_access': {'hide_private': False}, 'tokens': ['58fbdfdf149400b9', '550f2637e212e241'], 'state': 'asleep', 'in_service': False, 'id_s': '***', 'calendar_enabled': True, 'api_version': 73, 'backseat_token': None, 'backseat_token_updated_at': None, 'ble_autopair_enrolled': False}}
2024-05-12 09:05:34.631 DEBUG (MainThread) [tesla_fleet_api] Sending request to api/1/vehicles/***
2024-05-12 09:05:34.743 DEBUG (MainThread) [tesla_fleet_api] Response Status: 200
2024-05-12 09:05:34.744 DEBUG (MainThread) [tesla_fleet_api] Response JSON: {'response': {'id': ***, 'vehicle_id': ***, 'vin': '***', 'color': None, 'access_type': 'OWNER', 'display_name': '***', 'option_codes': None, 'granular_access': {'hide_private': False}, 'tokens': ['***', '***'], 'state': 'asleep', 'in_service': False, 'id_s': '***', 'calendar_enabled': True, 'api_version': 73, 'backseat_token': None, 'backseat_token_updated_at': None, 'ble_autopair_enrolled': False}}

Even though custom_components.teslemetry matched the log lines I got after turning on debug logging via GUI. What's the right logger component value(s) that you want debug output for ? tesla_fleet_api also?

[fhteagle]

Oh and instead of continue_on_error: true , I implemented a workaround via template values to make sure the charge limit is always going to move at least 1.

Example:

service: number.set_value
data:
  value: >-
    {{ [[50, states('number.mycar_charge_limit')|int + 1,
    states('input_number.mycar_eco_charge_target')|int,
    states('input_number.mycar_calendar_charge_target_min')|int + 4 ] | max, 100
    ] | min }}
target:
  entity_id: number.mycar_charge_limit

Its a kludge at best, but it does work.

[fhteagle]

I just noticed the 1.9.5 pre-release and manually installed it (since it was not showing up in HACS even after a GUI force refresh). Looks like ignoring already_set did the trick, and the service call is proceeding even when sending the existing value.

[Bre77]

From my perspective, its still nicer if you dont make a pointless API call when the value wont change, but I also 100% get how much easier it is to just call it every time to be sure. The HA UI doesnt make the service call unless the value changes, but I dont want to code that into the integration because there may very well be situations where you need to force it.

1.9.5 was a pre-release, so you just have to tick the beta box in HACS I believe. It will be a general release after some more testing. I am glad the already_set fix seems to be working.