thanks for the quick fix! (still got to change line 29 though… 
)
Oh, yeah. Well, I think that’s a leftover from custom_updater days. I should probably just remove it, since it’s not used anymore.
o dear, that wasn’t my intention at all. On the contrary, I am glad you still have it, since I don’t use HACS to update my stuff, and do it all manually. I like it very much to be able to see in the source code itself which version it is.
Ok. I’ll fix it and re-release as 1.11.2 (and delete the bad 1.11.1 release.)
EDIT: Done…
Released 1.11.2
Fixed wrong version number in device_tracker.py.
1 Like
@pnbruckner did you already take a look at the ping_arp device tracker?
This one seems to work really well too see whether a phone is at home.
Cheers,
Ronald
Hi Ronald,
By ping_arp I assume you’re referring to this:
I know I tried the standard ping, and some related, device trackers when I first starting using HA about a year and a half ago, but after some monitoring decided they didn’t help in my scenario. I.e., very seldom did they change before the GPS-based trackers did. But maybe it’s worth taking a look at this “new” custom integration.
Now having said that, I’m not sure how ping_arp applies to this topic, other than it could be used as yet another input to the composite tracker.
As you may or may not be aware, the current implementation uses version 4.0.2 of the package timezonefinderL. It also causes that package (and dependent packages, such as numpy) to be installed whether or not you’re using them (i.e., via the time_as option.)
I’ve created a beta with a new config option whereby you can specify which timezonefinder package you want to use, and optionally its version. It also only causes the package(s) to be installed if you’re actually using them.
If anyone is interested in trying out the beta you can find it here:
https://github.com/pnbruckner/ha-composite-tracker/tree/tzf-config
Please note that it requires HA version 0.98.0 or greater.
The main reason for creating this was to control the timezonefinder package and version. I’m not too crazy about the newer version of timezonefinderL (4.0.2.) I actually like the older version (2.0.1), which seems to work better in my situation. Also I wanted to provide the option of using the “full blown” timezonefinder package. (Note that timezonefinderL is a “lite” version of timezonefinder.)
The other reason was to not install this package (and its dependent packages) if you’re not using them (via the time_as option.) Note, however, if you’ve already been using the composite integration these packages have already been installed. If your time_as config does not require them, and you want to remove them to save space or whatever, you’d have to manually uninstall them.
Anyway, as always, feedback, good or bad, is most welcome!
I started getting this after the 0.104 update. Only difference is it’s now listed as a warning. Any thoughts?
2020-01-25 09:20:31 WARNING (SyncWorker_0) [custom_components.composite.device_tracker] device_tracker.john_s_iphone_unifi unsupported source_type: None
2020-01-25 09:20:31 WARNING (SyncWorker_9) [custom_components.composite.device_tracker] device_tracker.sue_s_iphone_unifi unsupported source_type: None
Is there something I need to define that I’m not when it references unsupported source_type: None?
For reference below is my composite definition:
device_tracker:
- platform: composite
name: John Tracker
time_as: device_or_local
entity_id:
- device_tracker.john_s_iphone_unifi
- device_tracker.jiphone
- platform: composite
name: Sue Tracker
time_as: device_or_local
entity_id:
- device_tracker.sue_s_iphone_unifi
- device_tracker.siphone
The composite tracker needs to know what type of tracker the input entities are in order to know how to use their information. It purposely treats GPS based trackers differently than other kinds. If that information is missing then it can’t use the input entity’s data.
Normally that is considered an error, and if it happens twice in a row for a particular entity, it will stop watching that entity. Unfortunately, many device_tracker entities don’t have all their attributes when they are restored at startup. The composite ignores that situation if an update for an entity comes before HA is fully initialized. (If it happens then it will just be logged in a DEBUG message.) But once the system is up and running, if it happens, a warning is generated the first time it happens, and an error for the second (in a row), and as I mentioned, it will stop watching that entity. Apparently this scenario happens with some trackers, even after HA is fully initialized. Not much I can do about that.
Please make sure you’re using the latest composite tracker. I did make some changes in 1.10.1 to try to improve the situation (although that was released way back in November. The latest release is 1.11.2.)
Thanks for the reply. I am on the latest version. I am of the belief this is related to the way 0.104 changed loading entities in their system as this wasn’t an issue previously. And if I remove a bunch of the things it’s loading, like a couple YAML files full of SNMP sensors, the warnings go away.
So this may or may not be an issue with the composite platform as much as it may be something with the way HA now loads things. In some ways it sounds like the issues will go away later as things get loaded but reading the release notes, who wants a bunch of errors on the screen that may go away the next check the system does. Not sure about anyone else, but I’m reloading my system a lot as I change things.
Like another thing that comes up is an error on loading the weather data so doesn’t display other than an “F”. The logs says it will try again in 19 minutes so assuming it eventually works, the GUI will be messed up for a while. Not related to composite, but just trying to figure out the cause overall.
I might be able to work around the issue (of an invalid state caused by restoring) by ignoring the first update for each input tracker no matter when it happens (as opposed to only ignoring before HA is fully initialized.) That should prevent the useless warnings.
EDIT: I opened this issue.
Released 2.0.0
Please note that it requires HA version 0.98.0 or greater.
Adds option to select timezonefinder package. See composite integration config options and example full config.
Released 2.1.0
Ignores first update for each input tracker if bad, regardless of when that first update comes. Should eliminate useless warnings after restart about unsupported source_type (due to partial restore of input entities’ attributes.)
I suppose I need to add this to HACS somehow, because I can’t find it in HACS. Help, please 
You’ll have to ask someone who uses HACS. I don’t and haven’t even tried it in a long time.
You can use my custom integration without using HACS. The instructions tell you how to manually install it.
I use it through HACS, its called just ‘Composite’, custom repository is ‘https://github.com/pnbruckner/ha-composite-tracker’
Ok, thanks
HI Phil,
after having updated to the new composite release, I see a lot of these:
2020-03-15 21:40:54 ERROR (MainThread) [homeassistant.config] Platform error: device_tracker
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config.py", line 752, in async_process_component_config
platform = p_integration.get_platform(domain)
File "/usr/src/homeassistant/homeassistant/loader.py", line 277, in get_platform
f"{self.pkg_path}.{platform_name}"
File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
File "<frozen importlib._bootstrap>", line 983, in _find_and_load
File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 728, in exec_module
File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
File "/config/custom_components/composite/device_tracker.py", line 26, in <module>
from .const import (
ModuleNotFoundError: No module named 'custom_components.composite.const'
Is this a bug, or do we need to set extra config settings, which I obviously missed?
thanks for having a look
update
Ive filed an issue on your repo, but maybe it is a HA update issue? After reverting to the previous 2.1.0 release, I still see this on config check:
Ill await your analysis, before filing this in the HA repo.
just so you know, taking the Composite integration out removes the config check error, so it definitely is an incompatibility between HA 106.6 and Composite
yes, thanks, it made me see I missed the const.py (all along). Don’t understand why it didn’t error out before, but it didn’t.
Check gave a valid config so, restarting now …
thanks