Feature request: Detect Bluetooth from Phones without pair

[kw123]

the error comes from printing to log file.. thats an easy fix. later today

but that does not stop the program, it just skips the reading of the device for one round

I am looking into optimizing the BLE connect process, testing things


Karl

[Hackencrash]

1.17.19 Stable so far - uptime = 10.5 hours

I can now see 3 processes corresponding to my 3 BLE devices (phones)

[kw123]

Good to hear. I will be out starting Wednesday next week for 3 week. Would like to get it stable before then.



Sent from my iPhone using Tapatalk

[kw123]

as I am leaving on Wednesday.. any problems with v .19 ?

I have some small fixes - mostly language -- I would like to post before off to Europe

[Hackencrash]

I have to say that the 19 version has proved very reliable - not a single failure

I understand that my setup may not be the same as others, but I did some tests between serial and parallel operation and parallel using the Broadcomm chipset Bluetooth detects quicker by about 3 seconds with 3 phones in different combinations in parallel mode with either no gap or a 2 second gap between disconnected reads.

The scheduled nightly reboot I have never got to work, but in a strange way this has proved useful as it confirms the reliability of this version shown by the uptime

Good work Karl

[kw123]

for the BLEconnect issues:

1. Hackencrash, could you post your iPhpne setup, i.e. do you have BLE connected to another device and if so how many and is it BLE4.x

2. I believe that if you have multiple BLE pairings setup on your iPhone it stays up more likely ... to be tested.

Karl

[kw123]

found a way to reduce the timeout:

Code: Select all

sudo timeout -s SIGINT 1s hcitool cc 54:9F:13:3F:95:26; hcitool rssi 54:9F:13:3F:95:26; hcitool tpl 54:9F:13:3F

will limit the wait time to 1 seconds

will add this when I am back, needs a bit more testing

Karl

[kw123]

With this mod the reaction time to recognize a returning iPhone seems to be down to less than 3 seconds max and it worked for several hours without issue.


Sent from my iPhone using Tapatalk

[Hackencrash]

Wow that's really good!


Sent from my iPhone using Tapatalk

[kw123]

Setting timeout to 1 sec and with "check continuously" the theoretical max time to recognize is ~1.2 secs. Realistically its around 2 seconds.
The fastest reaction time is probably ~ 0.2 secs after ble gets turn on.

A question. You don't seem to have the issue that your iPhone goes to "sleep" and not answer the ble-connect request.
How did you setup your iPhone?



Sent from my iPhone using Tapatalk

[Hackencrash]

I do have the issue where iPhones and Samsungs go to sleep, but what's important to me is the first detect time when I get near the house so I can have a verbal doorbell by name. Your discovery of the timeout property helps with this a great deal.

Once detected, I reduce piBeacon scans down to once every 10 minutes (and I have Fingscan to cover over any Bluetooth service blips - thank you for this Plugin too!).

Now, although I can announce when people arrive, I can't announce when they leave. I know piBeacon can do triangular positioning based on received power using multiple rPi's, but currently this is only useful if you're prepared to have your phone battery flattened by turning up the amount you Bluetooth ping your device to a few seconds.

If it could be possible, based on a movement sensor or door sensor or whatever to initiate an ad-hock Bluetooth ping from the piBeacon devices, then it would be very easy to discover who was in which room or who was leaving the house, etc. without using any phone battery up at all.

Just a passing thought...

This is by far the best plugin in the world ever!

[Hackencrash]

I've had a little play with v1.17.22 and wow yes it does detect fast!

I have noticed a problem with "Run BLEconnect in Parallel", "try continuously" and 1 second BLE timeout where it brought two phones (BLE Devices) up at once where only one came back to the house (me!). This eventually fixed itself and I've only spotted this happening once so far so it may be a one-off?

Perhaps the above could be fixed with timings, but the next value on from "try continuously" is 2 seconds which is a bit bigger than I was hoping to try next.

Please can we have some log rotation on the BLEconnect.log and audit.log files as setting Debug=3 on the rPi caused my blueberry to die as these files filled-up the whole of the remaining space on the SSD disk!

Great update - very fast at detection of phones

[kw123]

I can fine tune the options when I am back.

For the log: I had logfile magement but I moved it to the system folder as the opsys should take care of it. I can add that back. .. When I am back. But debug level 3 is very verbose and should not be used for a longer time. .. Only for real debugging and to analyze short bursts of data





Sent from my iPhone using Tapatalk

[Hackencrash]

Thanks for the .23 version

With the issue I'm noticing with two phones showing "up" on first connect when only one phone is present - this may be a status display specific issue as the other phone that says "up" but really isn't doesn't trigger any events whereas the real one does. I'm using Fingscan to trigger events.


Sent from my iPhone using Tapatalk

[kw123]

I can only check this when I am home in May.


Sent from my iPhone using Tapatalk