Cool, thx! Would be extra-informative, not only for the front-end experience, but certainly also for debugging purposes…
1 Like
Released 1.2.0, which adds support for bluetooth trackers and binary sensors.
1 Like
HI,
giving your script a serious try, it errors out with this:
018-09-26 16:48:57 ERROR (SyncWorker_7) [homeassistant.components.python_script.meta_device_tracker.py] Error executing script: 'NoneType' object is not callable
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/python_script.py", line 166, in execute
exec(compiled.code, restricted_globals, local)
File "meta_device_tracker.py", line 66, in <module>
TypeError: 'NoneType' object is not callable
and
018-09-26 17:03:24 ERROR (SyncWorker_8) [homeassistant.components.python_script.meta_device_tracker.py] Error executing script: 'NoneType' object is not callable
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/python_script.py", line 166, in execute
exec(compiled.code, restricted_globals, local)
File "meta_device_tracker.py", line 45, in <module>
TypeError: 'NoneType' object is not callable
the script which calls the python_script runs fine, and I get all relevant notifications:
update_meta_device_tracker:
alias: 'Update meta device tracker'
sequence:
- service: python_script.meta_device_tracker
data_template:
entity_id: '{{entityid}}'
- condition: template
value_template: '{{fromstate != tostate}}'
- service: notify.notify #logbook.log
data_template:
title: 'Meta Tracker updated:'
message: >-
{{ states[entityid.split('.')[0]][entityid.split('.')[1]].name }} is {{ tostate }} at {{ as_timestamp(now()) | timestamp_custom('%I:%M:%S %p') }}.
Apparently some error is found in the python, or a variable/entity isn’t set correctly. How would that be possible if the notifications that use the same entities show perfectly following the states of all device_trackers I entered?
NOTE: I found a bug that affects binary_sensors. Please do not use with binary_sensors until I get it fixed, hopefully later today. Sorry for any inconvenience.
The bug inadvertently changes the state of binary_sensors in the state machine to ‘home’ or ‘not_home’. This could easily affect how the binary_sensor is used elsewhere.
Released 1.3.0, which adds entity_id and last_entity_id attributes and fixes above mentioned bug affecting binary_sensors.
got a link?
If I click the previously posted link there’s 404…
nevermind, its been a long day… https://github.com/pnbruckner/homeassistant-config/blob/master/custom_components/device_tracker/composite.py
Yep, that link should always work for the latest release of this custom component. You might also want to consider using the Custom Updater.
yes i am using that, but not on Lovelace yet, so the state if that sensor is somewhat cryptic:
I instaand version 1.3 just now, and it works fine! that is, on 1 of the 2 device_trackers it shows all devices it is made of, on the other, it shows only 1 in the entity_id attribute.
Does it list all devices immediately or do the have to be seen to change state before it lists them?
only the 1showing
both showing
You need to update the custom_updater. 
The newest version shows the number of updates available instead of a useless timestamp.
They are added to the entity_id tuple as they change state and they’re actually used to update the composite device.
hmmm:
018-09-27 07:24:58 ERROR (MainThread) [homeassistant.setup] Error during setup of component custom_updater
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/setup.py", line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/custom_updater.py", line 73, in setup
config_show_installabe)
File "/config/custom_components/custom_updater.py", line 142, in __init__
self.cache_versions()
File "/config/custom_components/custom_updater.py", line 169, in cache_versions
local_version = self.get_local_version(card[0])
File "/config/custom_components/custom_updater.py", line 395, in get_local_version
resources = self.get_resources()
File "/config/custom_components/custom_updater.py", line 382, in get_resources
if content['resources'] is not None:
KeyError: 'resources'
guess I’ll have to look at the component’s issues page…
Maybe this:
and/or this:
yep, that’s me 
thought i’d file an issue, and read the lovelace issue, of which I cant make a solution yet in the non-lovelace setting.
Who’s you? hvbhome? Kind of sneaky using different usernames here and in github! I’ve been on other community sites that require (and verify) using the same username on both. Helps to avoid confusion.
sorry… not my intention at all. Had my GitHub account before I joined the community I guess, or the other way round, don’t really remember. Will see if I can change that. Otoh, some of the dev’s have multiple personalities too…
I suspect you can’t change your username in either (although I don’t know for sure), but if you at least use the same avatar/icon/whateritscalled on both, that would help people realize it’s the same person on both sites.
I’ve added my Bio to make it clear, hadn’t given it a thought before tbh. Didn’t want to hide in any way.
@Mariusthvdb @pnbruckner The updater was all kinds of broken for a while, most issues (at least then one I know about) should be resolved now, sorry about that.
1 Like
HI Phil,
after renaming one of my composite device_trackers to a name with a space in it, I got invalid slug errors
File "/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/config_validation.py", line 215, in slug
raise vol.Invalid('invalid slug {} (try {})'.format(value, slg))
suggesting to change the device_trackers name from first second to first_second. And of course that’s was already the case.
Thought it might have been a cache thing so first cleared that, and restarted. No succes. Then I deleted the device_tracker to be rebuilt. No change. I have deleted the complete instance, deleted the known_devices. And rebuilt is again. No change.
I now have created the same device_tracker setup with only a singel word name, and immediate succes…
Could this be a bug?
The name parameter will be used as the “object ID” of the device_tracker, which is the part of the entity ID after the dot. Entity IDs cannot contain spaces, either in the domain (the part before the dot) or in the object ID.
So my question is, why do you want it to have a space? Why don’t you just use the standard customization mechanisms to give it a nice friendly_name?
The only thing I can do is to call the “slugify” utility (which I do in the Life360 platform) to make sure the name will pass the “slug” validation that takes place in the device tracker component level code (which is what is failing and throwing the exception in your case.) But that will just change your name with a space to a name with the space replaced with an underscore.
I guess I didn’t expect anyone to specify an object ID with a space. But I suppose not everyone knows the details of entity IDs, domain names and object IDs, so it probably doesn’t hurt to add the call to slugify to prevent this from happening to someone else.
HI,
thx for explaining, at least now I know why this is happening (no bug) …
I was expecting the device_tracker would automatically get the name device_tracker.part_one, if I use Part One in the components Name field…
Of course I will use, and already use as a matter of fact, the possibility of the friendly_name, either in the known_devices, or in dedicated customizations. Hence no issue if you couldn’t ‘de-slugify’ , but nice if you could