Using service to set number.mycar_charge_limit to its current value gives error, blocks automation about hass-teslemetry HOT 7 CLOSED

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.

from hass-teslemetry.

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

from hass-teslemetry.

@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 ([email protected]), or Discord.

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

from hass-teslemetry.

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?

from hass-teslemetry.

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.

from hass-teslemetry.

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.

from hass-teslemetry.

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.

from hass-teslemetry.