A new device tracker

[Mark Hurley]

I'm heading down the path of making a new device tracker - can you share some sample outputs, how it works currently, etc?

[Paulus Schoutsen]

The device_tracker is build on top of device scanners. Have a look at the Netgear device scanner to see what is expected:

https://github.com/balloob/home-assistant/blob/dev/homeassistant/components/device_tracker/netgear.py

On Mon Nov 24 2014 at 3:59:15 PM Mark Hurley <markp...@gmail.com> wrote:

I'm heading down the path of making a new device tracker - can you share some sample outputs, how it works currently, etc?

--
You received this message because you are subscribed to the Google Groups "Home Assistant Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to home-assistant-dev+unsub...@googlegroups.com.
To post to this group, send email to home-assistant-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/home-assistant-dev/8eb3477c-9317-477c-9c91-70914eeff940%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[phlepper]

I don't think my router is compatible with the existing devices supported (it's an "Actiontec Q1000" DSL modem).  But rather than creating a device_tracker / scanner to support it, I'd like to create a more "manual" device tracker.  I use Tasker on my phone and it already can detect when I'm home and when I leave and takes certain actions based on those "events".

So I'm thinking of creating a device_tracker component that would be similar to the lights "demo" component which would support the states and services but doesn't "automatically" change states.  Instead I would call the component's service API to set a particular device as "home" or "not home" which I could do from Tasker. Then the changes of states could be used by Home Assistant to turn on lights or what have you.

Before I started though, I was wondering if anyone else had gone down this path.  I'm brand new to HA (just installed it last weekend), so I don't want to reinvent the wheel and also wanted to propose the idea in case there are some fundamental flaws with it ;)

phlepper

On Monday, November 24, 2014 at 5:07:41 PM UTC-7, Paulus Schoutsen wrote:

The device_tracker is build on top of device scanners. Have a look at the Netgear device scanner to see what is expected:

https://github.com/balloob/home-assistant/blob/dev/homeassistant/components/device_tracker/netgear.py

On Mon Nov 24 2014 at 3:59:15 PM Mark Hurley <markp...@gmail.com> wrote:

I'm heading down the path of making a new device tracker - can you share some sample outputs, how it works currently, etc?

--
You received this message because you are subscribed to the Google Groups "Home Assistant Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to home-assistant-dev+unsubscribe@googlegroups.com.
To post to this group, send email to home-assi...@googlegroups.com.

[Ryan Kraus]

My first recommendation would be to first consider using the Nmap device tracker. This is hardware independent as far as your router is concerned. You will only need to give your phone a static IP in your router's DHCP server. 

However, if you are dead-set on creating your own component to work with Tasker on your phone (nothing wrong with that), then I would not recommend modeling it after the demo switch. The switch will show an on/off toggle switch on its card in the frontend. This may not be desirable as it would allow you to manually toggle your home idicator (possibly by accident). Unless you want this ability, in which case, keep on keeping on.

I would recommend modeling your component after the sensor/demo component. This, however, leads to an obvious issue of not having a built-in api call to toggle your device. Not to worry, though, you could then create your own HTTP handlers and bind them to custom addresses on the built-in HTTP server. You can see an example of this in the components/api.py file.

That is how I would tackle this. Someone else most probably has a better idea, but that is how I think I would tackle that problem. If you are looking for a challenge, definitely give building your own module a try. Its pretty easy in this platform. I am putting the finishing touches on my first.

[Austin Hendrix]

The NMAP device tracker doesn't require devices to have a static IP
address; it resolves IP address to MAC addresses and tracks the MAC address.

That said, I think an alternate device tracker which listens for updates
from the device itself would be a good addition to the tracker suite.

The nmap tracker works fine for my android device, but it doesn't track
my roommate's iPhone; I suspect because his phone is disabling its wifi
to save power. A tracker where the phone reports its state to HA would
almost certainly be more reliable and just as power-efficient.

I'm not familiar with Tasker, but it seems like it would be a good place
to start.

-Austin

On 04/15/2015 05:21 PM, Ryan Kraus wrote:
> My first recommendation would be to first consider using the Nmap
> device tracker

> <https://home-assistant.io/components/device_tracker.nmap_scanner.html>.

> home-assistant-...@googlegroups.com.

> To post to this group, send email to
> home-assi...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/home-assistant-dev/8eb3477c-9317-477c-9c91-70914eeff940%40googlegroups.com

> <https://groups.google.com/d/msgid/home-assistant-dev/8eb3477c-9317-477c-9c91-70914eeff940%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Home Assistant Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to home-assistant-...@googlegroups.com
> <mailto:home-assistant-...@googlegroups.com>.

> To post to this group, send email to
> home-assi...@googlegroups.com

> <mailto:home-assi...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/home-assistant-dev/ee3ac1fd-3e02-455a-a466-ebe92d84bebd%40googlegroups.com
> <https://groups.google.com/d/msgid/home-assistant-dev/ee3ac1fd-3e02-455a-a466-ebe92d84bebd%40googlegroups.com?utm_medium=email&utm_source=footer>.

[phlepper]

Thanks Austin and Ryan!

I set up NMAP (didn't realize it was router independent) and it seems to be working okay (doesn't pick up my daughter's windows phone, but picks up my android and iphone okay).

I'm still pursuing the "manual" approach and I'm pretty close to having the initial portion done but I have a question: 

Does anyone know how I should be accessing the DeviceTracker object from within the "DeviceScanner" object (e.g., NmapDeviceScanner)? 

I'd like the  "manual" version to return a list of devices based on what is currently in the DeviceTracker "tracked" list that have a state of "STATE_HOME".  Basically there is no "scan" required because devices are manually changed from home to away, but the DeviceTracker object expects the scanner to return a list of all devices that are "home".  So the easiest answer would be to just return the list of devices that DeviceTracker already knows are "home".  

I thought I could use "self.tracked" in the "scan_devices" method, but self is apparently DeviceScanner and not DeviceTracker (DeviceTracker has a device_scanner member that points to the DeviceScanner object).

Being new to python, I'm wondering how I can navigate from the DeviceScanner back to the DeviceTracker object (if possible)?

Here's a snippet of the code (this is in the xxxDeviceScanner object):

=====

def scan_devices(self):

        # Since this is all handled manually, always return the devices

        # from the tracked list that are "at_home" (DeviceTracker will interpret these as "at_home" again)

        self.devicelist = []

        for device in self.tracked:    <======== this doesn't work because self is not the DeviceTracker, but the DeviceScanner

            if device.state == STATE_HOME:

                self.devicelist.append(device.name)

        return self.devicelist

====

Thanks,

Paul

[Ryan Kraus]

Austin, 

Thanks for the correction.

Paul,

It looks like the scan_devices method is indeed used by the DeviceTracker to retrieve status from the DeviceScanner. In fact, that and get_device_name are the only methods that are called by the DeviceTracker. The module level function get_scanner is also called to create your device scanner. 

Self indeed will be the DeviceScanner and it appears that there is no direct way to go back up to the DeviceTracker as its instance is never given to the scanner and is not stored as a global constant anywhere. It does, however, create a service call inside of Home Assistant that you could use to force a reload. Something like this should do the trick (or be kinda close):

# at the top of your code
from homeassistant.components.tracker import SERVICE_DEVICE_TRACKER_RELOAD

# where you want to force a reload
hass.services.call(SERVICE_DEVICE_TRACKER_RELOAD)

This doesn't fully solve your problem as your scanner still doesn't know what it is tracking. However, it doesn't necessarily have to care. When devices report their home or away status to your scanner, they could report their name and their state. You then store this data indiscriminately in your device scanner and return the list of devices that have reported a home status to you. This, however, will lead to an issue that when you restart Home Assistant, your object will "forget" devices that have not yet reported in.

Another option would be to have your DeviceScanner read the known devices file for itself and then know the names it is looking for. You could assume either home or away when Home Assistant starts.

A third option (sorry for rambliness of this email) would be to save a file in the config directory that indicates each devices last known state. This could compliment either of the options above.

Basically, the biggest obstacle with Home Assistant tracking devices manually like this is that when it is off, it doesn't know what happened. The current device trackers can rely on physical states that they can poll and check. You wouldn't have that luxury. It is certainly not a dead end, just an obstacle.

At some point in the future (although it is lower on my list) I want to implement an MQTT component that would allow Home Assistant to communicate with a nifty app called OwnTracks to receive not only home/away indicators, but also exact locations. Then maybe put a map on the frontend showing device locations. It might be a bigger undertaking than what you are doing, I'm not entirely sure, but if you want to steal that idea and try it yourself, I would not be the slightest bit offended.

Sorry, that was a lot of rambling. I hope it all made sense.