I’m not familiar with Apple products so you would have to try it and see…its also possible that your iPhone would just not bother to attempt re-negotiation with the network until it wakes up again.
There is also no guarantee that a shorter lease will cause it to send out updated ARP (address resolution protocol) announcements before they expire in the pfSense ARP table (what is actually being used to determine if someone is “home” in the tracker) – this is a problem I have with my Android phone where it won’t actually re-announce ARP until it expires in the table and briefly goes away if its sleeping during that time.
On a small home network the increased traffic probably won’t hurt anything but keep in mind ALL devices will be subject to the new shorter time, remember to change it back if you experience other issues or if it doesn’t help. Typically most DHCP clients will attempt to renew their lease at half the time remaining (so if its 1 hour, they will attempt renew at 30 minutes) and to do this they have to come out of any power-saving-standby mode to talk which will result in worse battery life across the board.
In the integration I created I have the unique ability to actually control the arp table directly as well. The logic I’ve implemented is every <poll interval> I check if the mac is in the arp table and if so the device is considered online, if not it is considered offline. However, immediately after the arp table is checked, I remove the arp entry (only for the tracked device(s)) which ultimately ensures the device must communicate with pfSense every <poll interval> to be considered home.
In a stereotypical setup (mobile devices that come and go and fetch some background data) the results are very consistent and predictable.
That seems like it would create an insane amount of extra traffic, and also not work well with phones/tablets that go to sleep for extended time periods? Unless you then ping everything but then it will wake up and kill the battery fast (been there, done that).
If you’re referring to extra arp traffic (arp flooding) in practical terms it’s highly unlikely. It only wipes the entries for the specific devices that are tracked (it doesn’t wipe the entire arp table).
My experience with iOS is that during extended periods of sleep it neither strains the battery nor goes offline completely (I’m set at a 2.5 minute poll interval).
Ah, yeah I’m polling every ~2-3 seconds (and tracking many devices - not just people) because I have things that need to happen in near-real-time to keep people happy.
A few examples:
-Radios that turn off as someone comes home (has to be fast enough to stop people manually turning them off and then never turns on)
-Air purifiers shutting off when the TV turns on (again…has to be fast so people don’t keep shutting them off manually)
-Multi-factor stuff to compute if an authorized person came home and unlock doors (e.g. person + their car + door opener used = unlock door from garage) has to happen fast though so it beats them getting out and walking to the door to be useful.
-Thermostats readjust when anyone comes home so someone doesn’t manually shove them to an unreasonable temp and its heating/cooling before they see it
-Turn on lights as they walk in (home/not-home overrides motion because dogs set them off all the time)
In my case I’d much rather have “false positive” for 15-20 min thinking people are home than even 30 seconds “false negative” not detecting someone who is home
Yeah that’s a very rapid interval. To me I would split the use-case into probably 2 categories:
mains powered stuff
transient devices that are on battery (ie: phones)
For mains powered stuff a ‘ping’ tracker seems the best candidate as battery consumption is not an issue. For battery powered transient devices there are definitely lots of trade-offs to consider and there’s certainly no ‘silver bullet’. My integration is more focused on the “replace nmap” use-case than anything else. For rapid detection I use ibeacons+mobile app which also provide micro location logic (ie: not am I simply home, but what room am I in), but obviously that doesn’t work for ‘dumb’ devices which can’t have the mobile app installed
Thanks for the integration, I seem to be stumbling at the first hurdle of installing the integration in Home Assistant. when I choose Pfsense it states config flow can not be loaded and the logs state Error occurred loading configuration flow for integration pfsense: cannot import name ‘SensorEntityDescription’ from ‘homeassistant.components.sensor’ .
thanks, I managed to get to the same conclusion that it was down to the HASS version. I was a couple of versions back and as soon as I upgraded it worked a treat. Many thanks for taking the time to respond
