Identify people by mobile phone

Good progress.

Hoping you noticed and did this points from the flow description:

  • Install sudo pip install paho-mqtt netaddr on your Linux.
  • Ensure the MQTT broker is up and running on the Linux where the ptracker is intended to run.
mosquitto_sub -t "#" &
mosquitto_pub -t "my/test/" -m "test message"

this should echo the 'test message' to the shell.
If works, please, for debug purposes disable autostart and restart of daemon node, kill the ptracker in the shell and run it manually in foreground.
Copy-paste the prints of 2-3 minutes of run or the crash stack.

Thank you.

How do I kill 'ptracker.py' in the shell?

Here's screenshot of running ptracker.py manually in foreground.

Cheers from David.

Hi,

Hoping you noticed and did this points from the flow description:

  • Install |sudo pip install paho-mqtt netaddr| on your Linux

Yep that was done as per you initial instructions.
Just checked and got a message saying 'Requirement already satisfied'

  • Ensure the MQTT broker is up and running on the Linux where the
    ptracker is intended to run.

I've got a couple of MQTT In and Out nodes on the same flow as your
'flow' to test that 'mosquitto' is working.

Cheers from David.

David, you found my bug!
Thank you!

I fixed it in version 0.5.1 (Bugfix: network config parsing was not enough robust.) Published.
Please, give it another try manually.

OK - give me 5-mins and I'll report back

Hi,
Looks like SUCCESS - yippppppeeee
See attached screenshots.

Cheers from David

Hi,
I've switched the settings back on in the Daemon node.
It now shows it's running.

Cheers from David

Thank you for update, David.
Now we can work on more-or-less generic logic to take actions based on presence/absence of users :wink:

Hi,
Just spotted a minor 'typo' disppeared is spelt with an a 'disappeared'.

Tried to find where to correct it - but failed.

Cheers from David.

PS: One quick question - what's the update checking-time?

Hehe, that's not quick question. That's the tricky one. To avoid quick battery drain on the handset the ping is once in 80 seconds when the status is "seen". Once handset disappeared (i'll fix the typo soon, thank you for attention), the pinging runs once in 20 secs. This allows to discover a person/handset pretty quick when approaching the WiFi AP or router.

To avoid network abuse, ping is ping. However, once a day "MAC-to-IP reinventory" is performed by nmap.

Thanks for the detailed answer to my 'quick' question.

Rdgs - David

I have invested close to $700 (five Happy Bubbles BLE sensors and a half dozen BluKii beacons) and 40 hours in my attempt to use BLE for presence at home. While it is possible to use BLE as a binary presence sensor for arrival, BLE is not, because of the process latency, effective for creating departure events that will lock the house while the user is there to hear the door lock.

BLE is also not a reliable solution for locating objects inside a house. Here is the salient sentence from the conclusion of a study that I wish I had found before my investment of time and money into BLE: "The original goal of this research was to develop an improved indoor positioning system using iBeacon technologies. However, after numerous and extensive experiments, we realized that the signal variation was too high to retrieve accurate distance estimation for designing a reliable and robust localization system." This summary aligns perfectly with my R&D work. BLE may be effective for triggering advertising content in a retail sales space. However, the accuracy of BLE devices for positioning within the confines of a house is not useful.

Further, because BLE is not able to provide an accurate location, it is not possible to consistently and accurately determine the motion of an object that is "leaving" the house and "moving" to the outside.

Others may have mentioned here the problems with using a cell phone to determine presence. The first day I tuned on presence detection in my house full of iPhones, I learned the hard way that the iPhone goes routinely to sleep, which causes it to disconnect from the network. I received a text every 30 minutes through the night as iPhones woke up and reestablished their network connections.

The Android does not demonstrate the same behavior as the iPhone and is fairly reliable for determining presence. However, it is not perfect.

A summary of my discovery:

The iPhone, Android, and BLE are all able to provide an "arrival event" with differing degrees of latency. The android that my wife keeps in the glove box of her car just for presence arrival can effectively unlock the door as she arrives in the driveway. As a binary "presence" sensor, BLE and Android are pretty reliable. Note that the Android creates phantom departure events from time to time. Unless it is always moving around, the iPhone is not reliable as a persistent presence sensor because of its tendency to drop and reconnect to the network.

Because "not at home" is dependent upon the latency of the detection of a device departure from the network, none of these devices are reliable as a way to lock a house if the requirement is to hear the lock close while the user is within hearing range of the door lock.

I have arrived at the conclusion that RFID and NFC are going to be the most reliable means of "touchless" arrival and departure. I have found that the most reliable is the actual door lock. Until I roll out my esp32/RFID solution, my presence detection is an active approach using a Schlage Sense deadbolt and NodeRed sequences. Everybody in the household has a dedicated access code. There are also NodeRed sequences that capture lock and unlock events using the knob on the inside as well.

My motive in sharing here is time savings for those who are in the discovery phase. While there are some who report success using BLE and mobile phones for presence, my experience has shown that none are an effective way to lock a house if the lock use case requires hearing the lock actually lock.

Hope this helps.

1 Like

That is certainly not a general statement that can be made. It may well be true in your particular case, but it is not true for all. Which version of Android is the phone running? Later versions have become much more aggressive in switching off the wifi after a couple of minutes of non-use. Also I think it may vary between phone manufacturers though I have not got enough evidence to be certain of this.

That is really helpful, thanks for sharing.

You might also have specifically called out the other problem with Bluetooth - it is still crazy expensive, especially for beacons. Not sure if that might not be because of licensing issues as well which may mean that the costs won't come down like it has for WiFi. But I can say for certain that at a low level, Bluetooth is madly complex.

I'm no expert for sure but my take on all of this is that currently, individual presence detection is still too unreliable, too complex and trying to make it reliable becomes very expensive, very quickly.

I can't see anything I could implement cheaply that would also pass the "family test".

Nor would I be in any way happy to rely on any of the current "smart" locks which are still proving themselves regularly insecure or buggy.

One day I might find some time to experiment with NFC tags.

I do hope, though, that someone proves me wrong.

After a bit of trail and error got the script running, but i'm getting a "Error: Network configuration is weird.". Any restrictions regarding network configuration?

The error means 'ifconfig' command returned nothing or gibberish.
The script is designed to run on Raspbian. It won't work on Windows and some Linux distribution which don't have ifconfig utility.