PHK a needs to be restarted periodically.

[rawmean]

I use PHK which runs on a raspi 2 with an iPhone app. When I run PHK everything works and I'm able to control my devices with Siri.
But, the PHK bridge become undiscoverable the next day even though the PHK is still running on raspi. Everything starts to work again if I kill PHK and restart it. My email: lesswire1@gmail.com
Thanks much for sharing this great code.

[eriksmets]

Same here. I'm running it as a service, so i just tell cron to run /usr/sbin/service homekit restart every 12 hours.

[etwmc]

Have you updated the code?
There is a bug in the code before which make the code unusable after a period of time, and there's also a bug fix for 8.2 which prevent the accessories to run for a long time, or being discovered.
So that might cause some trouble?

Wai Man Chan
Sent from my iPad

On Mar 20, 2015, at 10:38 PM, eriksmets notifications@github.com wrote:

Same here. I'm running it as a service, so i just tell cron to run /usr/sbin/service homekit restart every 12 hours.

—
Reply to this email directly or view it on GitHub.

[rawmean]

Thanks for the quick response.
I have pulled the current version from github and merged.
I am not running PHK as a service with a cron job. Is that required? I’m just running it manually and even when iPhone cant discover the bridge, the PHK process is still running (verified by 'ps aux | grep PHK’).
I’ll try running it as a service and see if that fixes the problem.

On Mar 20, 2015, at 7:41 AM, etwmc notifications@github.com wrote:

Have you updated the code?
There is a bug in the code before which make the code unusable after a period of time, and there's also a bug fix for 8.2 which prevent the accessories to run for a long time, or being discovered.
So that might cause some trouble?

Wai Man Chan
Sent from my iPad

On Mar 20, 2015, at 10:38 PM, eriksmets notifications@github.com wrote:

Same here. I'm running it as a service, so i just tell cron to run /usr/sbin/service homekit restart every 12 hours.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub #40 (comment).

[rawmean]

Thanks. Is running PHK as a service a work-around for a bug? When I do “ps aux | grep PHK” I can verify that the process is actually running and has not stopped, but iPhone app cannot discover it after a while.

On Mar 20, 2015, at 7:38 AM, eriksmets notifications@github.com wrote:

Same here. I'm running it as a service https://gist.github.com/elvisimprsntr/75dcee2e9b432b721b6e, so i just tell cron to run /usr/sbin/service homekit restart every 12 hours.

—
Reply to this email directly or view it on GitHub #40 (comment).

[etwmc]

The first thing to try is disconnect the iPhone and the device from the network, and connect again.
Then, You might need to delete the accessory in your iPhone and re-add it.
And if you don't see it from in discovery, you need to wipe the HomeKit database.
It seems Apple has protection measures in HomeKit, where changes in Bonjour record could prevent the connection, and any accessories with multiple error could be added to a blacklist, which prevent interact with without a wipe.

Wai Man Chan
Sent from my iPad

On Mar 21, 2015, at 12:57 AM, Ramin notifications@github.com wrote:

Thanks. Is running PHK as a service a work-around for a bug? When I do “ps aux | grep PHK” I can verify that the process is actually running and has not stopped, but iPhone app cannot discover it after a while.

On Mar 20, 2015, at 7:38 AM, eriksmets notifications@github.com wrote:

Same here. I'm running it as a service https://gist.github.com/elvisimprsntr/75dcee2e9b432b721b6e, so i just tell cron to run /usr/sbin/service homekit restart every 12 hours.

—
Reply to this email directly or view it on GitHub #40 (comment).

—
Reply to this email directly or view it on GitHub.

[eriksmets]

The 'restart-cronjob' is a workaround for this bug, the service makes it so that PHK autolaunches on boot or after a fatal error.

[etwmc]

Find the bug:
On Linux, the system would wait for a long time (or forever, haven't tested it yet), when the client (your device) is disconnected from the server.
Since the code is originally targeting MCU, I set a hard limit on how many connection the program accept (which is 20, by default)
Given the nature of your iDevice, you will disconnected from the server many times of the day, which could acclimated and fill the limit rapidly.
A fix is currently testing. Meanwhile, raising the numberOfClient in Configuration.h to a higher number (e.g. 100) could delay the problem.

[rawmean]

Thanks for the response. I’ll try your fix. It’s been working great since I created a cron job to restart the service periodically.

On Apr 8, 2015, at 10:41 AM, etwmc notifications@github.com wrote:

Find the bug:
On Linux, the system would wait for a long time (or forever, haven't tested it yet), when the client (your device) is disconnected from the server.
Since the code is originally targeting MCU, I set a hard limit on how many connection the program accept (which is 20, by default)
Given the nature of your iDevice, you will disconnected from the server many times of the day, which could acclimated and fill the limit rapidly.
A fix is currently testing. Meanwhile, raising the numberOfClient in Configuration.h to a higher number (e.g. 100) could delay the problem.

—
Reply to this email directly or view it on GitHub #40 (comment).