First, this is nothing to worry about. I’m assuming you see these only once per device at startup, is that right? Also, notice they are WARNINGs, not ERRORs.
What I believe is happening here (and I see it too sometimes) is that when the composite tracker starts up it gets the current state of the watched entities. However, if this happens early enough in the startup sequence, then although there are entries in the state machine for the entities, those states are coming from the database, not from the entities being updated by their platform code. In this case it seems the states are incomplete. I specifically don’t let that “count against” the entities during startup. (However, after startup, each watched entity is only allowed two “strikes”. I.e., the first problem is also considered a WARNING, then after that it’s an ERROR and the composite will stop watching that entity.)
So, again, bottom line is, this isn’t a problem. If you don’t like seeing the WARNINGs then you can change the log level for custom_components.device_tracker.composite to error.
Just a question as I’m just now getting into presence. I’ve been trying out both owntracks and life360. I do have your life360 component installed but got confused trying to get all the other things installed. Any plans on incorporating at least your life360 or at best all of this as an official hassio add-on? It would also be nice to have one place to go to in order to install everything. Life360 mentions “custom updater”. Clicking that link says to click a link to “custom updater”. Then another link for “Tracker card”, etc.
I would love to have the custom components I created become official components, but I don’t have the time to dedicate to making that happen, at least not anytime soon. Also I don’t use hassio and have no idea how to make add-ons for it.
Custom Updater is not required to install or use my custom components, although taking the time to install it and get it working can make using my custom components, and others as well, easier.
@pnbruckner , you helped me on my GPS python script and with the newer updates to HASS are you running into issues with your component reverting to cached data due to restore_state? I may have to re-work my entire setup in this area as a result but I remembered seeing this topic and may look to it as part of my re-work.
Per the discussion in the Life360 Tracker topic I am also working on adding time zone reporting support to this custom component. The docs haven’t been updated yet, but basically, if you add the following config item:
times_as: device
then it will try to determine what time zone the device is in. Obviously, this requires GPS data from the input tracker(s.) There is a new attribute named time_zone which will contain the name of the time zone (if possible), and the last_seen attribute will be reported in that time zone (as opposed to UTC, which it was before.) If the time zone cannot be determined, then it will fall back to reporting in the time zone specified in HA’s configuration.
There are two other choices for the new times_as config option – utc (which is the default) will show last_seen in UTC (as before), and local will show it in the “local” time zone (i.e., the time zone specified in HA’s configuration.) For both of these options it will not attempt to determine the time zone where the device is, and there won’t be a time_zone attribute.
If you’d like to give this a try, you can grab a copy of the beta here.
Note that if you specify times_as: device, then on the next restart HA will (potentially) need to install two Python packages: timezonefinderL and numpy. This might cause that restart to take a little longer. Also, if you’re running on a Raspberry Pi, you may need to install libatlas (which numpy requires on recent pi installs.) You can install it with this command:
It’s getting late here but I couldn’t resist trying it.
I am assuming I need libatlas3 as I don’t get the new attributes in the composite tracker.
If that is the case is this possible running hassio?
EDIT: Thinking about this, even though I would far rather, and to me it makes much more sense to, have this functionality in the composite tracker, would I be right in thinking that with the extra Python packages needed there is an extra processing overhead than when using the new Life360 component? If so, is it significant?
The only new attribute would be time_zone. To get that (and last_seen in the time zone of the device’s location) you need to add times_as: device to your composite config(s.)
FYI, the code that gets and uses the time zone is pretty much duplicated in the life360 & composite trackers. The composite tracker does not take time_zone from the input tracker(s) (e.g., life360); it figures it out itself based on the composite GPS data. (So, you can get device time zone data from any GPS-based tracker now. E.g., let’s say you were only use one, like Google Maps Location Sharing. You could “wrap” a composite tracker around it and get the time zone data.)
Regarding the additional packages used by the life360 & composite trackers to get time zone data (and only if you use times_as: device), there are only two - timezonefinderL, and numpy (which timezonefinderL uses.) timezonefinderL is the “Lite” version of timezonefinder. numpy is a package used by some standard HA components (like the Binary Trend Sensor.) So, really, I’m only introducing one new package.
Regarding libatlas, you only need to install that if you’re running HA on a pi and that pi is configured to use piwheels. I’ve only learned about this recently, but I think that applies to most newer installations of Raspbian. Basically, if you try to use this stuff and you get errors from numpy about a .so file missing, then you need to install libatlas (using the command I provided above.) This is the exact same scenario as if you use the standard Binary Trend Sensor (or any other standard component that uses numpy, of which I think there are a few.)
Sorry, I’ve been really busy again today.
I can report that the composite device tracker shows the correct timezone text.
The last seen times report correctly too. I’m not sure what else I can do to test this, I might move timezones in a couple of weeks but that is by no means certain.
I’m very happy with this, I can now reinstate the code I wrote to limit unsociable notifications!
I also noticed my nightly snapshot last night was bigger, I guess that is all the new Python libraries….
Ok, I have given this some more thought and I am having second thoughts…
For my use I am not actually interested in the last seen time as much as I am in the time zone and hence the offset from the HA time.
Let’s say a device is off line for several hours but we know that it is (was) 5 hours ahead. It is therefore always five hours ahead irrespective of when it was last seen. I would say that knowing the time zone offset is going to give the actual local time of the device more accurately, more often than knowing the local last seen time.
Maybe you missed this in the other thread, but you can derive the offset from last_seen, even if it’s old (because you’re using its tzinfo, not its absolute time):
{% set n = now() %}
{{ (n.astimezone(state_attr('device_tracker.XXX', 'last_seen').tzinfo).utcoffset() -
n.utcoffset()).total_seconds()/3600 }}
This will calculate the offset in hours, regardless of how long ago last_seen represents, as long as the device is still in the time zone it represents. (Of course, if the device has gone off line and HA can no longer get updates from it, there’s obviously no way to know if the device has crossed into another time zone in the meantime.)
That’s just the way it comes out. I format code snippets using the “three back-ticks” before and after technique, and normally I don’t use a format descriptor (like python, etc.)
I don’t know if this is useful. I’m only posting this for your information if it is, but I got an error today (no apparent consequences for me but it might be something you want to know about)…
2019-01-19 11:23:05 ERROR (MainThread) [homeassistant.core] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
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/device_tracker/composite.py", line 269, in _update_info
attrs = {ATTR_TIME_ZONE: tzname or STATE_UNKNOWN}
NameError: name 'STATE_UNKNOWN' is not defined
I’m looking for feedback on a side effect of the new feature I’m adding that determines time zone from the GPS coordinates and enables reporting time in that time zone. The issue is the size of additional Python packages required to make these determinations. Since I’m adding these features to my Life360 custom platform as well, it has the same issue. Please see this corresponding post for details. If you have any feedback, please comment in that topic so the conversation can be in one place. Thanks!
