TypeError in process_trigger: timedelta minutes receives string ("0") instead of int

[fsokolovsky]

Hi, thanks for this great integration!
I am seeing repeated errors when person_location.process_trigger is called:

TypeError: unsupported type for timedelta minutes component: str
  File "/config/custom_components/person_location/process_trigger.py", line 158, in change_state_later
    point_in_time = datetime.now() + timedelta(minutes=minutes)

I'm using configuration.yaml:

person_location:
  google_api_key: !secret google_mapapi_key
  language: sk
  region: EU
  follow_person_integration: false
  extended_away: 0
  just_arrived: 0
  just_left: 0
  person_names:
    - name: Johny
      devices:
        - person.johny
        - device_tracker.Johnyapp

What happens

In debug log I can see that extended_away, just_arrived and just_left are loaded as strings:

'configuration': {
  'configuration_from_yaml': True,
  ...
  'extended_away': '0',
  'just_arrived': '0',
  'just_left': '0',
  ...
}

When code later does:
pli.configuration[CONF_HOURS_EXTENDED_AWAY] * 60
the result is still a string, and timedelta(minutes=minutes) crashes with TypeError.

The values extended_away, just_arrived, and just_left should be parsed and stored as numbers (int/float), so multiplying by 60 and passing them to timedelta(minutes=...) always works without errors.

I fixed this locally by adding type conversion in change_state_later:

try:
    minutes_val = int(float(minutes))
except (TypeError, ValueError):
    _LOGGER.warning("[change_state_later] (%s) invalid minutes=%r -> defaulting to 0", entity_id, minutes)
    minutes_val = 0

Environment

Home Assistant Core 2025.8.x (Supervised on Debian)
Integration version: 2025.08.09
Python 3.13

[rodpayne]

Thanks for pointing this out. I haven't tested the YAML setup in quite a while, but maybe this never worked. I will check it out and fix it,

How it the YAML setup working for you otherwise?

[fsokolovsky]

It has actually been working fine for me so far, no issues until now.
This is one of the last integrations I still keep configured in YAML.
I guess it would make sense for me to migrate and set it up through the UI at some point :-)

I mainly kept it in YAML because of the old saying: “if it works, don’t touch it.”