issue 1: although the template device tracker is trigger based, if doesn't persist state over template reloads;
Work around is the use of extra reload/HA restart triggers to initialize the tracker (works ok)
issue 2: the template device tracker triggers a state changed, even when state and attributes are updates with identical values.
Work around is a condition in the root of the blueprint to filter out those updates without changes. Only consequence is that properties last_updated and last_reported won't update either.
Not a newbie. I'm following but can't say I understand 100%, so I think I'm lost -- figured I should ask around here.
At the moment, I have one entity phone_1 that was created via known_devices.yaml, which I understand will be gone.
And I use an automation and the device_tracker.see action, which will be gone also, to change the state of this device_tracker.phone_1 being home or away, based on 2 binary boolean entities. The automation is like this:
description: my automation to set the state of a device
mode: single
triggers:
- entity_id:
- input_boolean.example_1
trigger: state
- entity_id:
- input_boolean.example_2
trigger: state
conditions: []
actions:
- choose:
- conditions:
- condition: state
entity_id: input_boolean.example_1
state:
- "on"
- condition: state
entity_id: input_boolean.example_2
state:
- "on"
sequence:
- action: device_tracker.see
data:
dev_id: phone_1
location_name: home
- conditions:
- condition: state
entity_id: input_boolean.example_1
state:
- "on"
- condition: state
entity_id: input_boolean.example_2
state:
- "off"
sequence:
- action: device_tracker.see
data:
dev_id: phone_1
location_name: school
default:
- action: device_tracker.see
data:
dev_id: phone_1
location_name: not_home
Now, I'm at the Settings > Devices and services > Helpers > Create Helper > Template > Device tracker screen... and don't know how to replicate the automation in a template fashion.
This is the "state based device_tracker" we are talking about, right...?
Do I do trigger template thing?
Is the idea being we template the thing and declare home & give it a dummy gps position... or no gps position at all? Similarly do we declare not_home & give it a(nother?) dummy gps position...?
(Yup. I'm lost for sure.) (... which is why I'm here seeking help/guidance.)
= = = =
Wait, Nathan above is saying this new template device_tracker cannot be assigned to a person...? Wouldn't that be an issue? Wouldn't that why we encourage users to tie device tracker to a person to being with? If not an issue, what should we do instead?
This should go into the first box named "zones".
Leave everything else blank.
Of course the zones "home" and "school" need to be defined in HA. Since we don't use GPS position in determining the zone, the location of these zones does not matter.
EDIT: added additional logic, after edit of original post
The new template-based device tracker doesn't have the ability to set its own state. The device_tracker.see action has this capability, which I use frequently. I can set custom locations independent of defined zones or within a given zone but in different locations. Using the device tracker template version, it's not possible to modernize existing automations that use custom state setting. To fully replace device_tracker.see with a new solution, this capability would need to be added. This can be resolved by explicitly specifying a custom state name, replacing the zone name or not_home. If the state is undefined, it works as it currently does. I think this solution will satisfy everyone.
The capability already exists. You can set whatever zone you want, but it needs to exist in the system. Use the in_zones option. I'm not going to be changing the logic outside that.
e.g.
# FOR HOME
in_zones: "{{ ['zone.home'] }}"
# FOR NOT HOME
in_zones: "{{ [] }}"
# FOR ANOTHER ZONE
in_zones: "{{ ['zone.work'] }}"
What about different locations within a single zone? Should I create subzones within a zone? This only creates confusion in the system due to the number of zones. For example, the home zone is divided into an apartment, basement, garage, and laundry room. Furthermore, the automation concept determines whether a person, for example, has left the apartment but is nearby and still in the zone. Why doesn't the new solution fully replace the functionality of the old method? This causes chaos in automation and reduces its functionality. The new solution is partially inferior to the older one, when it should be the other way around.
I don't understand what else I can learn. I simply expect that when I change solutions, the new one will give me at least as much as the old one, or even more.
Not yet, it probably works, but I am irritated by the need to define many zones and subzones that are unnecessary for other purposes. In this respect, the new system is inferior to the old one.
What is a legacy device tracker and how do I recognize it? After reading Deprecation of legacy device tracker platform API | Home Assistant Developer Docs I come to the conclusion that a legacy device tracker is one that is not in config.yaml . Device trackers in the config.yaml have been introduced 2019 and are the better alternative. But google gemini tells me: " Remove the bluetooth_le_tracker block from your configuration.yaml file.". Iām confused.
