I could post this in project guidance (and maybe I will) but this seems 101-specific. I'd like to port my Uno project to 101, but it might not be feasible.

First, here's a description of my EXISTING project (Uno):

I own a driving school for teens, and we have 5 vehicles. In each car, I have audio/video surveillance and a DVR. (Occasionally I review recordings to assure quality service.) Some students object to surveillance and since legally we must have consent, I needed to give instructors the ability to turn surveillance off, but only for a limited time periods, and/or for a limited number of hours per day. (Because my employees don't like surveillance either, and might otherwise "forget" to turn surveillance back on.)

The project includes an Uno with a "clean" 9V power supply, two relays which are triggered by opening doors or turning the key (either of which turns on the Uno power supply) a module with two more relays controlled by the Uno to route power to the surveillance, and to the Uno itself. (So the Uno can hold its own power supply on for a time period after the doors have been closed and the key is not turned.) It also includes a small display and a button on the dashboard. Further, there is a realtime clock with a battery. The time of day isn't relevant, but the clock allows the system to handle "continuing" the current state after being powered down, as the most recent status and the time such status should expire is stored in EEPROM.

All this is working just fine.

Now here's what I'd like to add with a 101I'd like to be able to unlock the cars using any previously-recognized phone with bluetooth. That is... When the phone gets in range, the doors unlock. When out of range, they lock. (Ideally, with no phone app required, they'd just have to leave bluetooth on.) This would involve swapping the Uno for a 101 and adding two more relays. (And a lot of tinkering)

In case you're wondering why: Key fobs for electric locks are a logistical problem for us, because instructors take cars home, and I have a fleet runner who rotates the vehicles once a week... Usually late at night. He has to have access to all vehicles, and also keep each key with each vehicle (along with a fob or other means of opening the car), and yet the vehicles must also be secure. Even though I have a spare for each key and fob, I don't have 5 spares of everything. So, using a "lock box" outside each instructor's home is the most obvious solution. But there are issues with such boxes being broken into, and instructors have a tendency to take keys into their homes, forgetting to use the lockbox. (And requiring employees to mount something outside their house isn't cool.)

The scenario I prefer is: The key stays in the vehicle. (Hidden under the dash with a short chain.) No fob at all. Just an Arduino watching for previously-recognized phones to come into or out of range, locking and unlocking doors as appropriate. Every car can be opened by every listed phone in this manner. If an employee leaves the company, I can remove his/her phone from the recognized lists in each car. The Arduino doesn't have to connect to the phones (necessarily)... It just has to see them, recognize them, and respond.

I haven't really done any sketches for 101 yet, but I have already read these pages:

1) Unless I'm mistaken, the 101 would be the peripheral device, not the central device. As such, the phone isn't broadcasting the advertisements. But...

2) Maybe the phone could auto-connect such that the 101 could recognize its presence upon connection. Problem with that is, it has to either stay connected (which could interfere with connecting to other devices, such as the car's built-in bluetooth) or repeatedly attempt to connect to recognize that it goes out-of-range.

3) The range might be too long. (Such that if an instructor is working in his garage with his phone at night, the doors could unlock without his knowledge.)

4) The range might be too short. (I need it to behave consistently and painlessly, without forcing employees to wave their phone around to establish a connection.)

5) The time delay to observe the phone may be too long. (If an instructor is within 30 feet, he could be at the car within 2-3 seconds. Will he have to wait another few seconds for his phone to be recognized and the doors to unlock?)

You have the microcontroller with BLE, RTC and FlashMemory onboard, all in 1. What more could you ask for!

1 recomendation:

1) On a first pass make sure that any breakout boards/chips you wish to incorporate into your project communicate through I2C or SPI only and the libraries they are suppplied with do not depend on the uno avr or other uc architecture for that matter. No guarantee here, but this has worked for very well so far.

1 question:

2) How does your uno prototype "know" who to open locks for now? Are you already using BLE?

1 idea:

3) The onboard accelerometer might be able to be used as a safety lock in case someone tries to physically damage the device

1 thought:

4) For safety/security audits, I would definitely take advantage of the real time clock to time and date stamp activities.

Has a ble lock project in it. While not a curie/arduino101 specific project, I have learned a lot from this book and highly recommend it.

Your curie will be the peripheral, your phone the central. You phone will have to run a native app( requring java or swift programming perhaps) or a hybrid web app which consists of javascript/html/css with special libraries that will allow you to access the BLE hardware of your phone. You could use EvoThings, PhoneGap or the intel XDK for this. It might seem daunting at first, but once you get rocking with one of these you will love it. I like EvoThings a lot and have posted about it in this forum. I have tried PhoneGap, it is excellent as well and I am just now starting an edx course that teaches javascript/html/css using the intel XDK.

I don't think the phone will have to auto connect per se. Download the nrf master control app for your own phone/tablet/mobile device and see how many BLE devices you pick up. Other forum users have posted here on how to use the nrfMaster Control app with the curie/101.The curie will just advertise itself and your app can look for the lock and connect with it automagically or through user input. It should not intefere with the cars own BT/BLE, this is one of the advtantages of ble service adverstising.

My opinion is that you will have to have some kind of backend program running on a server that can communicate with the phone app that will allow you to control car access/phone permissions.

Not sure exactly how far BLE trasmits, although 30 feet sounds very reasonable.

Good luck on this exciting and interesting project! If I were you, I would sketch out the overall architecture and them prototype a system on your benchtop with the curie/arduino101 and let us all know about it!

To your question, I'm not using BLE or door unlocking at all right now. (The cars have a standard key fob for electric locks.) The existing and functional project is just to temporarily disable video surveillance in the cars.

*IF* I do this project, each car would just recognize individual phones. A given phone could open any of our cars if it's listed in each Arduino. It shouldn't be any harder than pairing a phone with the cars' existing bluetooth.

I have a dashboard interface consisting of one button and a small OLED display. One button is sufficient (in coordination with timing) to select the options: Disable video for 30, 60, 90, 120 minutes. (Or just "On".) The first press brings up the menu, then they tap to select the timeout, then 3 seconds later the menu disappears, displaying the current "Surveillance on/off" status and amount of time remaining.

I could hypothetically add another menu which appears only upon holding the button for a few seconds (maybe 10 secs), which in a similar manner could allow addition or deletion of any instructor's phone. (Those phones it can currently "see" but are not currently listed would be listed for possible addition, and those phones already stored would be listed for deletion.) Such a menu would probably be unseen by instructors unless they're adding their phone. If an employee leaves, for starters they would no longer have possession of any car, but I can promptly delete their phone from all cars.

Servers? Apps? Yikes... I got a business to run and time is money. Apps may be simple, but I don't want to do anything that inconveniences employees any more than a regular key fob.

I have also considered an alternative: No bluetooth, just a series of light sensors mounted to the windshield, where the user could "cover" each sensor with their finger in a sequence as a combination. (Potentially more durable and easier to mount without damaging the car than mechanical buttons -- But of course, this might not work well at night.)

Just to wrap up this thread: The item I said I "REALLY" need in post 3 exists. I bought a bunch of 315 MHz remotes and corresponding receivers from Adafruit. The web page says any unit will work with any other, even stating "There is no sub-addressing."

I would have beeen concerned that other people may have the same unit, and unlock my doors. But it's not actually true that they don't have addressing.

All fob and receiver can be addressed with solder bridges, (which must match on all fobs and receivers) with 6,561 combinations.

So... Whether this project is feasible or not doesn't matter, because this is a better solution.