mfkrause / homebridge-people-pro

Homebridge plugin that provides details of who is in a Home + History (powered by fakegato)
MIT License
41 stars 2 forks source link

MAC address not quite working? #15

Open HSkul opened 3 years ago

HSkul commented 3 years ago

Using both hostname and ip address the plugin seems to work pretty well with couple of exceptions (some could be my network). However, using MAC address Homebridge detects the state of the phone (present or not) correctly when Homebridge is restarted (like after config change) but it never updates it after that, even though the phone disconnects from the network (for more than 15min). I've tried few variations (pingUseArp true or false) and it doesn't seem to matter, it never gets updateed after restarting the service. Running Homebridge 1.3.4 and node.js 15.9.0 on Raspberry Pi Zero and here is a snippet from the config:

    {
        "people": [
            {
                "name": "MyPhone",
                "target": "aa:bb:cc:dd:ee:ff",
                "type": "motion",
                "threshold": 15,
                "pingInterval": 10000,
                "pingUseArp": true,
                "excludeFromWebhook": true
            }
        ],
        "anyoneSensor": false,
        "anyoneSensorName": "Anyone",
        "anyoneSensorType": "motion",
        "nooneSensor": false,
        "nooneSensorName": "No One",
        "nooneSensorType": "motion",
        "platform": "PeoplePro"
    }

Thanks, IC

mfkrause commented 3 years ago

Hey, are you running the newest version of the plug-in? There was a bug in a previous version that might have caused this. It should work in the newest version though. Otherwise, please note that ARP is generally way more unresponsive when it comes to these kinds of "online checks" than ping probes. It might take much longer than the configured threshold for the ARP tables to update and PeoplePro, therefore, recognizing a status update. This is due to how the ARP protocol works.

If you're sure that you're running the newest version and the status absolutely does not update even after, say, 30 minutes, please get back to me and I'll have a look at this.

HSkul commented 3 years ago

Thanks for looking into this.

I just updated to the latest version (0.11.5, was on the previous version) and I still can't get it to work. I've actually played around with all the settings (webhook, ARP, time) and it only seems to catch the initial state (at server startup) when MAC address is used. I watched the ARP table update on the Pi as I turned the wifi on my phone off and on and yes I can see that it takes some time for it to update. Disabled ARP and still no update. Not sure if this helps but the log only gets updated (on server startup) when the accessory has a positive state change for the phone (when MAC address is used). For example:

Phone-off --> start server --> Phone-on --> start server [phone detection is logged because state changed] Phone-on --> start server --> Phone-off --> start server [phone not detected is not logged even though state changed]

I'm pretty sure that was not the case when IP address or network name was used. I think it logged it each time a state was changed (obviously a server restart was needed to get it to change in those cases). But maybe that has something to do with initial state being not detected after restart and thus no update needed when phone isn't detected.

Let me know if there are any other things for me to test to help out.

IC

lakemike commented 3 years ago

I have the same issue. I am using MAC/ARP as well. The missing/present status is correctly recognized always after homebridge is restarted. Anything I could do to help testing? My homebridge is running on docker, latest homebridge-people-pro v0.11.6.

gegallego commented 3 years ago

Hi, I'm getting the following error when using a MAC address:

(node:2456) UnhandledPromiseRejectionWarning: Error: Command failed: arp -a

    at ChildProcess.exithandler (child_process.js:390:12)
    at ChildProcess.emit (events.js:400:28)
    at maybeClose (internal/child_process.js:1055:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:2456) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:2456) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.